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: 2420 bytes --]

On Tue, Oct 08, 2019 at 06:29:27PM +0200, 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? 

Oh, even better: I can call SetVirtualAddressMap() while still in 1:1,
just after ExitBootServices(), giving it 1:1-like map (for areas marked
with EFI_MEMORY_RUNTIME). This way I don't need to really map BootServices
areas (and exclude from Xen memory allocator), so there is no penalty
for systems with conforming firmware. And indeed calling
SetVirtualAddressMap() is enough for other runtime services (like
GetVariable*) to behave correctly, even if boot services are not mapped
anymore.
So, the only downside is incompatibility with kexec.

> Similarly to Andrew, I'd really prefer for Xen to work out of the box,
> with as little as possible manual tweaks needed.

> > Allowing SetVirtualAddressMap() when !KEXEC would be fine with me.
> > The fly in the ointment here is that we'd prefer not to have such
> > Kconfig options (at least not without EXPERT qualifier), as
> > (security) supporting all the possible combinations would be a
> > nightmare. If an EXPERT dependency is okay with you, then I'll be
> > looking forward to your patch.
> 
> EXPERT is fine with me.


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