Re: [Xen-devel] 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

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 25.09.14 at 02:11, <andrew.cooper3@xxxxxxxxxx> wrote:
> On 24/09/2014 22:10, Konrad Rzeszutek Wilk wrote:
>> (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.

Even if it was 64-bit code, %rbp being used as the base address of
a memory access in no way contradicts the use of %bh.

However, grepping through the SeaBIOS sources doesn't reveal
anything hinting at an instruction like this being present. Nor can I
find such a byte sequence in the binaries I have here (albeit if this
is compiled rather than assembly code, differences due to
different compilers being used may make it impossible for me to
find this).

> Either way, the presence of the .byte in the disassembly (whether 32 or
> 64bit) indicates a misaligned instruction instruction pointer.

Depending on whether this was on an AMD or Intel system, the
bytes past the ones constituting the first instruction may not be
valid. Which is supported by bytes 4-7 resembling the upper half of
a hypervisor address (which could be a leftover on the stack).

>> 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.

Could also be a build problem, considering that Konrad's own rebuilt
hvmloader didn't exhibit the issue.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel