From mboxrd@z Thu Jan 1 00:00:00 1970 From: Konrad Rzeszutek Wilk Subject: 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 Date: Thu, 25 Sep 2014 13:49:55 -0400 Message-ID: <20140925174955.GA31279@laptop.dumpdata.com> References: <0593b34d-9cc2-4f92-857b-5683892bfb1c@FTLPEX01CL01.citrite.net> <54235DC5.9090204@citrix.com> <542401430200007800038D22@mail.emea.novell.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1XXDBK-0000X9-36 for xen-devel@lists.xenproject.org; Thu, 25 Sep 2014 17:50:18 +0000 Content-Disposition: inline In-Reply-To: <542401430200007800038D22@mail.emea.novell.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Jan Beulich Cc: Andrew Cooper , xen-devel@lists.xenproject.org, m.a.young@durham.ac.uk List-Id: xen-devel@lists.xenproject.org On Thu, Sep 25, 2014 at 10:49:23AM +0100, Jan Beulich wrote: > >>> On 25.09.14 at 02:11, 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. It was, but not an obvious one. The seabios-bin RPM was built with 'CONFIG_XEN=n' and the Xen RPM was built with: "--with-system-seabios=/usr/share/seabios/bios.bin" which means that hvmloader slurped up an seabios BIOS binary that was not built for Xen support. Changing config.seabios-128k to have CONFIG_XEN=n to CONFIG_XEN=y and rebuilding both seabios and Xen RPMs fixed the issue. This is also tracked here: https://bugzilla.redhat.com/show_bug.cgi?id=1146260 > > Jan >