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

[Rich Persaud <persaur@xxxxxxxxx>]

On Nov 27, 2019, at 04:16, Jan Beulich <JBeulich@xxxxxxxx> 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?

If we take this thread as an example, a middle ground was found among 
developers motivated to maintain the workarounds for downstream projects with 
affected hardware.  Qubes, EVE & OpenXT are used on edge/client devices that 
often have (relative to servers) a shorter lifetime, with more device churn and 
support costs. 

These two initial options would address current pain points and enable the use 
of upstream Xen + EFI RS on more devices, e.g. for OTA updates with 
forward-sealed integrity measurements.  The line could change if more 
downstreams adopt the option and/or new devices appear that have both customer 
adoption and problematic firmware behavior.

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