Re: [Xen-devel] Xen 4.12 panic on Thinkpad W540 with UEFI mutiboot2, efi=no-rs workarounds it - Marek Marczykowski-Górecki

From: "Marek Marczykowski-Górecki" <marmarek@invisiblethingslab.com>
To: Jan Beulich <jbeulich@suse.com>
Cc: Andrew Cooper <andrew.cooper3@citrix.com>,
	xen-devel <xen-devel@lists.xenproject.org>
Subject: Re: [Xen-devel] Xen 4.12 panic on Thinkpad W540 with UEFI mutiboot2, efi=no-rs workarounds it
Date: Wed, 7 Aug 2019 17:51:12 +0200	[thread overview]
Message-ID: <20190807155112.GA3257@mail-itl> (raw)
In-Reply-To: <59f6c90b-3dbb-b0eb-ff45-0f8fd4c915de@suse.com>

[-- Attachment #1.1: Type: text/plain, Size: 3998 bytes --]

On Wed, Aug 07, 2019 at 05:33:05PM +0200, Jan Beulich wrote:
> On 07.08.2019 17:17, Marek Marczykowski-Górecki  wrote:
> > On Wed, Aug 07, 2019 at 04:45:43PM +0200, Jan Beulich wrote:
> > > On 07.08.2019 15:26, Marek Marczykowski-Górecki  wrote:
> > > > Hi,
> > > > 
> > > > Xen 4.12 crashes when booting on UEFI (with multiboot2) unless I disable
> > > > runtime services. The crash happens shortly after starting dom0 kernel.
> > > > Unfortunately I don't have serial console there, so the only log I have
> > > > is a photo of VGA console (attached). Below I retype part of the message:
> > > > 
> > > > (XEN) ----[ Xen-4.12.0-3.fc29  x86_64  debug=n   Not tainted ]----
> > > > (XEN) CPU:    0
> > > > (XEN) RIP:    e008:[<00000000000000f6>] 00000000000000f6
> > > > (XEN) RFLAGS: 0000000000010287   CONTEXT: hypervisor (d0v0)
> > > > ...
> > > > (XEN) Xen call trace:
> > > > (XEN)    [<00000000000000f6>] 00000000000000f6
> > > > (XEN)    [<ffff82d08026c6ad>] flushtlb.c#pre_flush+0x3d/0x80
> > > > (XEN)    [                  ] efi_runtime_call+0x493/0xbd0
> > > > (XEN)    [                  ] efi_runtime_call+0x441/0xbd0
> > > > (XEN)    [                  ] vcpu_restore_fpu_nonlazy+0xe7/0x180
> > > > (XEN)    [                  ] do_platform_op+0/0x1880
> > > > (XEN)    [                  ] do_platform_op+0xb9c/0x1880
> > > > (XEN)    [                  ] do_platform_op+0xb9c/0x1880
> > > > (XEN)    [                  ] sched_credit2.c#csched2_schedule+0xcd0/0x13a0
> > > > (XEN)    [                  ] lstar_enter+0xae/0x120
> > > > (XEN)    [                  ] do_platform_op+0/0x1880
> > > > (XEN)    [                  ] pv_hypercall+0x152/0x220
> > > > (XEN)    [                  ] lstar_enter+0xae/0x120
> > > > (XEN)    [                  ] lstar_enter+0xa2/0x120
> > > > (XEN)    [                  ] lstar_enter+0xae/0x120
> > > > (XEN)    [                  ] lstar_enter+0xa2/0x120
> > > > (XEN)    [                  ] lstar_enter+0xae/0x120
> > > > (XEN)    [                  ] lstar_enter+0xa2/0x120
> > > > (XEN)    [                  ] lstar_enter+0xae/0x120
> > > > (XEN)    [                  ] lstar_enter+0xa2/0x120
> > > > (XEN)    [                  ] lstar_enter+0xae/0x120
> > > > (XEN)    [                  ] lstar_enter+0xa2/0x120
> > > > (XEN)    [                  ] lstar_enter+0xae/0x120
> > > > (XEN)    [                  ] lstar_enter+0x10c/0x120
> > > > (XEN)
> > > > (XEN)
> > > > (XEN) *****************************************
> > > > (XEN) Panic on CPU 0:
> > > > (XEN) FATAL TRAP: vector = 0 (divide error)
> > > > (XEN) [error_code=0000]
> > > > (XEN) *****************************************
> > > > 
> > > > Any idea? Lack of serial console doesn't help with collecting logs...
> > > 
> > > May I suggest that you repeat this with a debug hypervisor, such that
> > > the call trace becomes more usable/sensible?
> > 
> > Actually, I've already tried, but every other build I try, I get even
> > less useful call trace, for example debug unstable build:
> > 
> >      Xen call trace:
> >         [<000000007b751c09>] 000000007b751c09
> >         [<8c2b0398e0000daa>] 8c2b0398e0000daa
> > ...
> >      GENERAL PROTECTION FAULT
> >      [error_code=0000]
> 
> But this makes reasonable sense: The faulting insn is "call *0x18(%rax)"
> and %rax is 6954b2b0, which points into a block of type
> EfiBootServicesData (and hence likely reused by the time of the crash
> for other purposes). Hence the "/mapbs" option of xen.efi might help
> here too, but iirc there's no equivalent for it in the MB2 case.

Oh, yes, indeed in Qubes we have /mapbs enabled by default with xen.efi.
I'd like to add it to MB2 case too. Is command line parsed at this point
(efi_exit_boot()) already? 

-- 
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

[-- Attachment #2: Type: text/plain, Size: 157 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel