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?