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

[Jan Beulich <jbeulich@xxxxxxxx>]

On 08.10.2019 13:50, Marek Marczykowski-Górecki  wrote:
> On Thu, Aug 08, 2019 at 08:03:49AM +0200, Jan Beulich wrote:
>> 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:
>>>> 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.
> 
> I explored it a bit more and talked with a few people doing firmware
> development and few conclusions:
> 1. Not calling SetVirtualAddressMap(), while technically legal, is
> pretty uncommon and not recommended if you want to avoid less tested
> (aka buggy) UEFI code paths.
> 2. Every UEFI call before SetVirtualAddressMap() call should be done
> with flat physical memory. This include SetVirtualAddressMap() call
> itself. Implicitly this means such calls can legally access memory areas
> not marked with EFI_MEMORY_RUNTIME.

I don't think this is quite right - whether non-runtime memory may
be touched depends exclusively on ExitBootServices() (not) having
got called (yet).

> Then I've tried a different approach: call SetVirtualAddressMap(), but
> with an address map that tries to pretend physical addressing (the code
> under #ifndef USE_SET_VIRTUAL_ADDRESS_MAP). This mostly worked, I needed
> only few changes:
>  - set VirtualStart back to PhysicalStart in that memory map (it was set
>    to directmap)
>  - map boot services (at least for the SetVirtualAddressMap() call time,
>    but haven't tried unmapping it later)
>  - call SetVirtualAddressMap() with that "1:1" map in place, using
>    efi_rs_enter/efi_rs_leave.
> 
> This fixed the issue for me, now runtime services do work even without
> disabling ExitBootServices() call. And without any extra
> platform-specific command line arguments. And I think it also shouldn't break
> kexec, since it uses 1:1-like map, but I haven't tried. One should
> simply ignore EFI_UNSUPPORTED return code (I don't know how to avoid the
> call at all after kexec).

That's the point - it can't be avoided, and hence it failing is not
an option. Or else there needs to be a protocol telling kexec what
it is to expect, and that it in particular can't change the virtual
address map to its liking. Back at the time when I put together the
EFI booting code, no such protocol existed, and hence calling
SetVirtualAddressMap() was not an option. I have no idea whether
things have changed in the meantime.

Jan

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