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

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