Re: Xen 4.14.0 fails on Dell IoT Gateway without efi=no-rs

[Roman Shaposhnik <roman@xxxxxxxxxx>]

On Thu, Aug 20, 2020 at 6:10 AM Rich Persaud <persaur@xxxxxxxxx> wrote:
>
> On Aug 20, 2020, at 07:24, George Dunlap <dunlapg@xxxxxxxxx> wrote:
>
>
> 
> On Thu, Aug 20, 2020 at 9:35 AM Jan Beulich <jbeulich@xxxxxxxx> wrote:
>>
>>
>> As far as making cases like this work by default, I'm afraid it'll
>> need to be proposed to replace me as the maintainer of EFI code in
>> Xen. I will remain on the position that it is not acceptable to
>> apply workarounds for firmware issues by default unless they're
>> entirely benign to spec-conforming systems. DMI data based enabling
>> of workarounds, for example, is acceptable in the common case, as
>> long as the matching pattern isn't unreasonably wide.
>
>
> It sort of sounds like it would be useful to have a wider discussion on this 
> then, to hash out what exactly it is we want to do as a project.
>
>  -George
>
>
> Sometimes a middle ground is possible, e.g. see this Nov 2019 thread about a 
> possible Xen Kconfig option for EFI_NONSPEC_COMPATIBILITY, targeting 
> Edge/IoT/laptop hardware:
>
> https://lists.archive.carbon60.com/xen/devel/571670#571670

Yup. Having that top-level knob is exactly what I had in mind as the first step.
We can debate whether it needs to be on or off by default later, but having
it is a very burning problem. Otherwise distros like EVE and QubesOS just
to give you two obvious examples have a very difficult time sharing "best
practices" of what works on those types of devices.

> In the years to come, edge devices will only grow in numbers.  Some will be 
> supported in production for more than a decade, which will require new 
> long-term commercial support mechanisms for device BIOS, rather than firmware 
> engineers shifting focus after a device is launched.

That's exactly what we're seeing with ZEDEDA customers.

> In parallel to (opt-in) Xen workarounds for a constrained and documented set 
> of firmware issues, we need more industry efforts to support open firmware, 
> like coreboot and OCP Open System Firmware with minimum binary blobs.  At 
> least one major x86 OEM is expected to ship open firmware in one of their 
> popular devices, which may encourage competing OEM devices to follow.
>
> PC Engines APU2 (dual-core AMD, 4GB RAM, 6W TDP, triple NIC + LTE) is one 
> available edge device which supports Xen and has open (coreboot) firmware.  
> It would be nice to include APU2 in LF Edge support, if only to provide 
> competition to OEM devices with buggy firmware. Upcoming Intel Tiger Lake 
> (Core) and Elkhart Lake (Atom Tremont) are expected to expand edge-relevant 
> security features, which would make such devices attractive to Xen 
> deployments.

Funny you should mention it -- APU2 is my weekend project for this
coming weekend to make EVE/Xen run on it out-of-the box. I'll be using
SeaBIOS payload for now, but the ultimate goal is to turn EVE into a
payload itself.

> We also need edge software vendors to encourage device OEMs to enable open 
> firmware via coreboot, OCP OSF, Intel MinPlatform and similar programs. See 
> https://software.intel.com/content/www/us/en/develop/articles/minimum-platform-architecture-open-source-uefi-firmware-for-intel-based-platforms.html
>  and other talks from the open firmware conference, https://osfc.io/archive

Thanks,
Roman.