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

["Marek Marczykowski-Górecki" <marmarek@invisiblethingslab.com>]

[-- Attachment #1.1: Type: text/plain, Size: 3820 bytes --]

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:
> >>> Regardless of SetVirtualAddressMap() discussion, I propose to
> >>> automatically map boot services code/data, to make Xen work on more
> >>> machines (even if _we_ consider those buggy). 
> >>
> >> I remain on my prior position: Adding command line triggerable
> >> workarounds for such cases is fine. Defaulting to assume buggy
> >> firmware is acceptable only if this means no extra penalty to
> >> systems with conforming firmware. Hence, for the case at hand,
> >> I object to doing this automatically; we already have the
> >> /mapbs workaround in place to deal with the case when xen.efi
> >> is used. Judging from the title here there may need to be an
> >> addition to also allow triggering this from the MB2 boot path.
> > 
> > What about mirroring Linux behavior? I.e. mapping those regions for the
> > SetVirtualAddressMap() time (when enabled) and unmapping after - unless
> > tagged with EFI_MEMORY_RUNTIME? 
> > Similarly to Andrew, I'd really prefer for Xen to work out of the box,
> > with as little as possible manual tweaks needed.
> 
> If there's going to be a config where SetVirtualAddressMap() is to
> be called - why not? But the same logic doesn't make sense when
> such a call won#t happen in the first place.

See my other email, I think I've found a better (simple and working!)
solution.

> >>> What if Xen was kexec'ed from Linux?
> 
> Honestly - I'm getting tired. You said yourself ...
> 
> >>> 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?

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

> >>> What about something in between: make this SetVirtualAddressMap() call
> >>> compile-time option (kconfig), depending on !CONFIG_KEXEC ? And when
> >>> enabled, properly handle SetVirtualAddressMap() failure.
> >>
> >> What is "proper handling" here?
> > 
> > Logging the error and either panic or disabling runtime services (I tend
> > to the latter).
> 
> Hmm, yes, disabling runtime services in this case makes sense.
> But are you sure a SetVirtualAddressMap() failure doesn't incur
> other potential issues later on? (Calling panic() is what I'd
> rather not call "proper handling", but rather "emergency
> handling".)

Well, as for being sure, one could say calling ExitBootServices() but
not SetVirtualAddressMap() definitely won't cause any troubles. I can't
say anything about UEFI for sure. But UEFI spec doesn't mention any side
effect of a failed call.

BTW Linux panic on failed SetVirtualAddressMap(). But on kexec, if
didn't received address map for EFI RS calls, it simply disable RS.

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

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

[-- Attachment #2: Type: text/plain, Size: 157 bytes --]

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