Re: Quarantined: Booting F21-Alpha-x86 iso image on Xen 4.4 with: io.c:206:d240 MMIO emulation failed @ 0008:ffff245f: 38 7d 2d 3d 02 83 ff ff da 95

[Andrew Cooper <andrew.cooper3@citrix.com>]

On 24/09/2014 22:10, Konrad Rzeszutek Wilk wrote:
> Hey,
>
> Tomorrow is Fedora 21 Alpha test day and I decided to try it
> one day earlier. The PV guests install just fine, but to my
> surprise the HVM ones crash. It did not matter what kind of
> ISO image I put in, it always crashed at:

<snip>

> (d240) Invoking SeaBIOS ...
> (XEN) io.c:206:d240 MMIO emulation failed @ 0008:ffff245f: 38 7d 2d 3d 02 83 ff ff da 95
> (XEN) hvm.c:1346:d240 Triple fault on VCPU0 - invoking HVM shutdown action 1.
>
> Which seem to be:
>
>    0:   38 7d 2d                cmp    %bh,0x2d(%rbp)
>    3:   3d 02 83 ff ff          cmp    $0xffff8302,%eax
>    8:   da                      .byte 0xda
>    9:   95                      xchg   %eax,%ebp

Hmm - %bh and %rbp in the same instruction looks wrong.  It would appear
that it is not, but I do believe you have told objdump that it is 64bit
raw x86.

Given that it is in the middle of SeaBIOS, I presume it is actually
32bit code, which would change %rbp to %ebp but keep all other decoding
identical.  At the very least, Xen could help us out by indicating which
processor mode it believes the guest is currently in, which would avoid
any ambiguity in the correct instruction decoding.

Either way, the presence of the .byte in the disassembly (whether 32 or
64bit) indicates a misaligned instruction instruction pointer.  Can you
disassemble SeaBIOS and work out what 0xffff245f is supposed to be, and
whether it is indeed misaligned?

>
> If I change the guest config to use QEMU traditional it all works
> fine.

Which means the difference between SeaBIOS and ROMBIOS, which I suspect
is the relevant point, rather than purely a Qemu issue.

At a guess, I would say that this is a bug in SeaBIOS which causes a
jump to a bogus address, which blows up some point later because of
0x2d(%[er]bp) being an MMIO address which is unclaimed by Qemu (or
invalid in the p2m), at which point Xen injects a #GP which turns into a
triple fault if an IDT has not yet suitably been set up.

Can you put a "dump_execution_state();" in hvm_triple_fault() to gather
rather more guest register state at the point of the crash?

~Andrew