Re: [edk2-devel] RFC: Universal Payload Interface

["Laszlo Ersek" <lersek@redhat.com>]

On 10/28/20 04:26, Ni, Ray wrote:
> Laszlo,
> Thank you for the comments.
> Reply inline.
> 
>> -----Original Message-----
>> From: devel@edk2.groups.io <devel@edk2.groups.io> On Behalf Of Laszlo
>> Ersek
>> Sent: Tuesday, October 27, 2020 10:21 PM
>> To: devel@edk2.groups.io; Ni, Ray <ray.ni@intel.com>
>> Cc: Zimmer, Vincent <vincent.zimmer@intel.com>; Ma, Maurice
>> <maurice.ma@intel.com>; Rangarajan, Ravi P <ravi.p.rangarajan@intel.com>;
>> Dong, Guo <guo.dong@intel.com>; Hau, Tze-ming <tze-ming.hau@intel.com>
>> Subject: Re: [edk2-devel] RFC: Universal Payload Interface
>>
>> On 10/23/20 03:18, Ni, Ray wrote:
>>> With the fact that there are many different firmware implementations, we
>> tried to decouple today's monolithic UEFI firmware binary to two independent
>> components: bootloader and payload.
>>
>> (1) "Bootloader" is an extremely loaded word. Regardless of everything
>> else in this topic, I strongly suggest picking a different name.
>>
>> We already have "Platform Init" or "PI"; maybe use "Silicon Init" or "SI"?
> I am a UEFI guy for many years. So your suggestion "PI" looks very friendly to me.
> But I am not sure if the audiences include broader people, like coreboot, SBL developers,
> do they like the names.
> 
> Personally I am open to any name as long as the concept is not changed: the binary blob
> is responsible to initialize the silicon.
> 
> 
>>
>>
>> (2) What is the *exact* use case (or workflow) that the proposed
>> interface enables, or improves?
>> What groups of people (what roles) are supposed to benefit from the
>> proposed interface?
> 
> 1. Unified UEFI Payload Binary.
> By standardizing the bootloader->payload interface, we keep in mind to move all
> platform/silicon specific implementation to bootloader and all the specific info is
> passed to payload through the standard interface such that the payload doesn't need
> to deal with concrete hardware but just the abstracted info. It gives possibility to create
> the unified UEFI payload binary that can run in any platform/silicon (off course, one binary
> per one CPU arch). Just like today's UEFI Shell.
> It's a huge save on validation side to every company that uses UEFI as boot solution for
> hardware.
> People may argue maintaining such a binary causes additional overhead. I agree.
> But I am optimistic on such direction. 
> (The code will be still in open source.)
> 
> 2. Bootloaders
> It shows an attitude of EDKII community that it doesn't restrict to use EDKII PEI as the
> only acknowledged silicon code execution environment. The standard interface as a promise
> allows any compliant bootloader to work with EDKII UEFI Payload.
> 
> 3. Payloads
> I saw different tries to change EDKII DXE environment for different hardware/OS.
> It may cause defragmentation of UEFI spec. The standard interface also allows any
> compliant payload to be created.

- I don't have anything against this, as long as existent platforms are
not required to adopt the new scheme.

- The above description helps, but it is *still* too generic for me to
understand:

(a) Intel already distributes Firmware Support Packages, which are
supposed to deal with RAM / chipset initialization, AIUI,

(b) the PI spec is not tied to edk2 PEIMs, and I don't see where EDKII
PEI modules are currently the only "acknowledged" silicon init
environment. The edk2 tree itself seems to contain platforms that don't
use the edk2 PEI module set at all, but (IIRC) jump from SEC to DXE. I
believe "ArmPlatformPkg/PrePi" and "ArmVirtPkg/PrePi" are related to this.

(c) Replacing edk2 DXE should already be possible without replacing the
edk2 DXE IPL PEIM -- isn't it enough to change the contents of the boot
firmware volume?

I haven't looked at the above interaces in detail for a very long time
now, but I feel we already have the necessary abstractions in place. So
clearly they are insufficient for *some* workflows / use cases. That's
what I'd like to understand more closely. What are the specific problems
with the edk2 offerings? Can you describe example activities that
vendors or other stakeholders would like to perform today, but they
can't, or at high cost only?

I'm quite "out of the loop" on how firmware is composed *in practice*
for proprietary / binary-only / multi-vendor platforms. With my
background in OVMF, I could be missing your point-of-view entirely.

Which is why I want to say very clearly that I'm not attempting to
"block" this proposal at all -- as long as it causes neither
regressions, nor new requirements, for existent platforms --; I just
think the limitations of the current interfaces / implementation, and
the desired improvements, should be written up precisely. Case studies,
actual projects etc would help.

(I understand that you referenced actual code already, but I don't have
capacity for reviewing code, without an actual use case for OVMF. Hence
my request for a natural language description.)

Thanks
Laszlo