Re: [Xen-devel] UEFI support on Dell boxes (was: Re: Status of 4.13)

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

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

On Wed, Nov 27, 2019 at 10:14:56AM +0100, Jan Beulich wrote:
> On 26.11.2019 22:20, Rich Persaud wrote:
> > As an intermediate step, could we have an umbrella opt-in
> > Kconfig option (CONFIG_EFI_NONSPEC_COMPATIBILITY?) that
> > enables multiple EFI options for maximum hardware compatibility?
> >  For this thread and Xen 4.13, that would be
> > EFI_SET_VIRTUAL_ADDRESS_MAP and efi=attr=uc.  If more
> > options/quirks are added in the future, downstreams using
> > EFI_NONSPEC_COMPATIBILITY would get them by default.
> 
> While I don't particularly like it, I'd be okay with having such
> an option, provided it doesn't hamper code readability too much.
> However - why would you stop at those two things? Why not also
> exclude reboot through UEFI (as indicated by Andrew), or use of
> runtime services as a whole? What about /mapbs? The fundamental
> problem I see here really is - where would we draw the line?

Yes, it isn't easy to draw that line for all the downstream projects at
once. For example it looks like efi=no-rs is an acceptable compromise
for Project EVE, while it isn't for Qubes or OpenXT. But moving from
"apply this set of patches" to "enable those options" would be an
improvement. 

Ideally Xen should work out of the box on as many boxes as possible. If
that means enabling some workarounds by default, I'm fine with it
(unless it _severely_ impact other configurations). In Qubes we struggle
with hardware compatibility because of large variety of client hardware,
firmware and configuration.  Whatever we say here, in the end it boils
down to "does project X work on my hardware?". Not sure about other Xen
use cases, but we prefer to have the answer "yes", whenever it's
reasonably possible. I think enabling efi=attr=uc and
EFI_SET_VIRTUAL_ADDRESS_MAP by default is a reasonable approach.
Defaulting to a different reboot method may be too, but I haven't seen
too many machines impacted by this particular issue. Maybe because
Xen+UEFI breaks much earlier there.

FWIW we do enable efi=attr=uc, /mapbs and /noexitboot by default (until
EFI_SET_VIRTUAL_ADDRESS_MAP was added).

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