[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] Xen 4.12 panic on Thinkpad W540 with UEFI mutiboot2, efi=no-rs workarounds it
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:
signature.asc _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxxxxxxxxx https://lists.xenproject.org/mailman/listinfo/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |