On 18/08/17 16:55, Konrad Rzeszutek Wilk wrote: > On Wed, Aug 16, 2017 at 06:47:23PM +0000, Andri Möll wrote: > >> (d1) Invoking OVMF ... >> (XEN) MMIO emulation failed: d1v0 16bit @ f000:0000ff54 -> 66 ea 5c ff ff ff >> 10 00 b8 40 06 00 00 0f 22 > That code is: > cripts/decodecode > Code: 66 ea 5c ff ff ff 10 00 b8 40 06 00 00 0f 22 > Code: 66 ea 5c ff ff ff 10 00 b8 40 06 00 00 0f 22 > sed: -e expression #1, char 1: unknown command: `-' > > Code starting with the faulting instruction > =========================================== > 0: 66 ea data16 (bad) > 2: 5c pop %rsp > 3: ff (bad) > 4: ff (bad) > 5: ff 10 callq *(%rax) > 7: 00 b8 40 06 00 00 add %bh,0x640(%rax) > d: 0f .byte 0xf > e: 22 .byte 0x22 > > Which looks to be garbage.
That is because you're disassembling it as 64bit code, not 16. :) The offending instruction is actually ljmpl $0x10,$0xffffff5c, and is almost certainly following a write to CR0 which enables protected mode. 0xea is not valid in 64bit mode. Decoding it is already complicated because it takes two adjacent immediate operands, with the offset encoded before the segment. There is no "immediate operand override" prefix in x86, so making the instruction usable in a 64bit code segment is tricky. Given how rarely it is used, I expect AMD decided it wasn't worth the effort or silicon trying to make it work. ~Andrew _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
