Hi, On 4/23/18 6:18 PM, Jan Kiszka wrote: > From: Jan Kiszka <[email protected]> > > The parser my bail out on opcode byte 0-2. > > Signed-off-by: Jan Kiszka <[email protected]> > --- > hypervisor/arch/x86/mmio.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/hypervisor/arch/x86/mmio.c b/hypervisor/arch/x86/mmio.c > index c1b9f10e8..775ec4b7b 100644 > --- a/hypervisor/arch/x86/mmio.c > +++ b/hypervisor/arch/x86/mmio.c > @@ -219,7 +219,7 @@ error_noinst: > > error_unsupported: > panic_printk("FATAL: unsupported instruction " > - "(0x%02x [0x%02x] 0x%02x 0x%02x)\n", > + "(0x%02x 0x%02x 0x%02x 0x%02x)\n", > op[0].raw, op[1].raw, op[2].raw, op[3].raw);
sorry for digging out this old patch, but I think we have a logical bug here: There are cases, where we jump to error_unsupported before all opcodes are set. In this case, the Hypervisor reports the wrong instruction, which really confused us for a while (Andrej found this). We have such a case, if decoding of op[0] fails. Jailhouse will then report sth. like: FATAL: unsupported instruction (0x83 0x00 0x00 0x00) Which is wrong, the code behind is: ffffffff819705d6: 83 78 08 03 cmpl $0x3,0x8(%rax) Which brought us to the next issue: CMPL might be intercepted, when accessing, e.g., PCI MMConfig space. In Linux' pcibios_add_device, we have the upper code fragment that accesses MMConfig with CMPL. Ralf -- You received this message because you are subscribed to the Google Groups "Jailhouse" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
