I would like to add a few notes to the meeting notes to clarify things a bit better.
These are far older than cbmem. Inside the coreboot tree those are even still called 'lb_table',
so it dates back from when the project was called LinuxBIOS.
'really isn't practical' is a very relative term here...
Monday I asked what existing firmware payloads (fwiw this is really a coreboot concept to begin with)
don't support coreboot tables that would benefit from having a 'universal' self describing handoff.
The answer is none: all existing firmware payloads support coreboot tables.
So the only thing not 'practical' here is that UEFI teams don't have control over the handoff structure
format that is inside coreboot and is used by coreboot payloads (coreboot tables). The proposed solution is a new format
that all payloads and coreboot ought to support. Needless to say that this is a lot of work (adapting both coreboot and
all existing payloads) with very little benefits for coreboot.
The current payload handoff method has a number of flaws that
they’d like to fix, such as the address for stack being
hardcoded.
Normally payloads set up their own stack very early on so this is not a problem. The context here, was that I voiced some
practical concerns about using CBOR as a handoff structure. LinuxBIOS or coreboot tables were carefully designed to be
very easy to parse. In fact so easy to parse that Linux payloads on x86 are loaded the following way:
- cbfstool has an assembly written trampoline (~150LOC) that parses the coreboot tables and fills in the zero page of Linux
- This trampoline is position independent and stackless for maximum flexibility
- cbfstool appends this trampoline to Linux payloads inside cbfs
- This is done so that coreboots runtime only knows how to load the 'SELF' format (simple ELF) which abstracts all the complexities of
payload formats away at buidtime (cbfstool). This is also how other formats are handled (elf, raw bin, FV, ...)
My objection to a new format like cbor was that it is likely very hard to parse using the same trampoline scheme.
It is likely possible to write a trampoline using a stack in C, but then again that just complicates things a lot needlessly
just to adopt a new format with probably little to gain.
* The coreboot project can, however, encapsulate a CBOR-based
handoff-structure into cbmem, similar to what we currently do with
ACPI tables.
I think this is about supporting both a CBOR-based handoff and coreboot tables at the same time.
My concerns here are that is requires some synchronization between both codepaths and just increases maintenance in general.
Introducing multiple codepaths to do roughly the same is an error we get bit by way too often. I think we should be
careful about this...
Additionally Intel was willing to look at using CBOR structures as
input and output to the FSP, so we could get rid of both the UPDs
& HOBs.
This seems like the real positive upshot of that conversation!