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

[Jan Beulich <jbeulich@xxxxxxxx>]

On 08.08.2019 04:53, Marek Marczykowski-Górecki  wrote:
> On Wed, Aug 07, 2019 at 09:26:00PM +0200, Marek Marczykowski-Górecki wrote:
> > On Wed, Aug 07, 2019 at 06:34:09PM +0200, Jan Beulich wrote:
> > > On 07.08.2019 18:04, Marek Marczykowski-Górecki  wrote:
> > > > On Wed, Aug 07, 2019 at 05:58:59PM +0200, Jan Beulich wrote:
> > > > > On 07.08.2019 17:51, Marek Marczykowski-Górecki  wrote:
> > > > > > On Wed, Aug 07, 2019 at 05:33:05PM +0200, Jan Beulich wrote:
> > > > > > > On 07.08.2019 17:17, Marek Marczykowski-Górecki  wrote:
> > > > > > > > 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?
> > > > > I'm struggling a little how to reply, considering that I've already
> > > > > said "iirc there's no equivalent for it in the MB2 case". So I guess
> > > > > I'm simply not understanding your question, or more specifically
> > > > > where you want to get with it.
> > > > /mapbs option is very specific to xen.efi. I'd like to add a means to
> > > > set map_bs variable in MB2 case too. I'm asking whether I can use
> > > > standard command line parser, or do I need something special extracting
> > > > it from MB2 structures directly.
> > > Well, efi_multiboot2() gets called from head.S, even before the
> > > (non-EFI only) cmdline_parse_early. I don't suppose there's a way
> > > to avoid mixing this new option into the "normal" command line,
> > > and hence there's also no way around peeking into the command
> > > line early. Of course there's the option to see whether what
> > > efi_arch_process_memory_map() could be deferred until later. But
> > > likely that would be a far more intrusive change than what you're
> > > considering to carry out.
> > Ok, regardless of adding proper option for that, I've hardcoded map_bs=1
> > and it still crashes, just slightly differently:
> >
> >      Xen call trace:
> >         [<0000000000000080>] 0000000000000080
> >         [<8c2b0398e0000daa>] 8c2b0398e0000daa
> >
> >      Pagetable walk from ffffffff858483a1:
> >         L4[0x1ff] = 0000000000000000 ffffffffffffffff
> >
> >      ****************************************
> >      Panic on CPU 0:
> >      FATAL PAGE FAULT
> >      [error_code=0002]
> >      Faulting linear address: ffffffff858483a1
> >      ****************************************
> >
> > Full message attached.
> After playing more with it and also know workarounds for various EFI
> issues, I've found a way to boot it: avoid calling Exit BootServices.
> There was a patch from Konrad adding /noexit option, that never get
> committed. Similar to efi=mapbs option, I'd add efi=no-exitboot too
> (once efi=mapbs patch is accepted).
>
> Anyway, I'm curious what exactly is wrong here. Is it that the firmware
> is not happy about lack of SetVirtualAddressMap call? FWIW, the crash is
> during GetVariable RS call. I've verified that the function itself is
> within EfiRuntimeServicesCode, but I don't feel like tracing Lenovo
> UEFI...
This suggests that the firmware zaps a few too many pointers
during ExitBootServices(). Perhaps internally they check
whether pointers point into BootServices* memory, and hence the
wrong marking in the memory map has consequences beyond the OS
re-using such memory?

A proper answer to your question can of course only be given
by someone knowing this specific firmware version.

Jan

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