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

[Jan Beulich <jbeulich@xxxxxxxx>]

On 09.10.2019 12:31, Marek Marczykowski-Górecki  wrote:
> On Wed, Oct 09, 2019 at 10:56:56AM +0200, Jan Beulich wrote:
>> On 08.10.2019 18:29, Marek Marczykowski-Górecki  wrote:
>>> On Tue, Oct 08, 2019 at 04:19:13PM +0200, Jan Beulich wrote:
>>>> On 08.10.2019 15:52, Marek Marczykowski-Górecki  wrote:
>>>>> In Linux case, it looks like it passes around the EFI memory map using
>>>>> some Linux-specific mechanism, but I don't find it particularly
>>>>> appealing option.
>>
>> ... that this would require Xen following a Linux protocol.
>> This is nothing that can work building on EFI interfaces alone.
> 
> Actually, there is something that could be used: presence of boot
> services. If the call to SetVirtualAddressMap() is bound to initial
> presence of boot services, then it surely won't happen after kexec, as
> boot services are not available anymore. In fact the patch I've sent
> does exactly that - call SetVirtualAddressMap() directly after
> ExitBootServices(), but I've realized this property only now. In this
> case, maybe kconfig option is not needed anymore?

I'm unaware of a property telling an EFI application whether
boot services are available. By the definition I know they're
available up and until ExitBootServices() gets called.

> BTW How runtime services work after kexec? I don't see EFI handles
> handed over kexec, are they somehow re-discovered?

What EFI handles are you talking about? For runtime services
what a consumer needs is a table pointer, which is a field
in the system table, which in turn is an argument passed to
the EFI application's entry point. I didn't think there are
provisions in the spec for either of these pointers being NULL.

Jan

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