Attention is currently required from: Arthur Heymans, Jérémy Compostella, Kapil Porwal, Nico Huber, Patrick Rudolph, Subrata Banik.
Julius Werner has posted comments on this change. ( https://review.coreboot.org/c/coreboot/+/81960?usp=email )
Change subject: arch/x86: Enable long mode entry into payload for x86_64 support ......................................................................
Patch Set 14:
(1 comment)
Patchset:
PS14:
Can you give an example where something like this hit x86 payloads in general?
Well, okay, most of these are probably somewhat platform- or payload-specific due to the simple fact that libpayload doesn't really do that much on its own. The most recent one I can find that would break something universal is the FMAP cache in CBMEM from 2019 (which is nowadays required by libcbfs). But I don't think people think about that direction of compatibility much when they add code (at least I don't, to be honest).
Anyway, I'm not trying to invalidate your use case if you say you have one. But I still think there's a practical problem here in terms of getting this supported in a truly backwards-compatible manner. We need to have a purely 64-bit handoff flow for X86S eventually (so might as well design that right now rather than kicking that can down the road), but in order to make that compatible with old 32-bit coreboot the payload would need two entry points. It's impossible to do that cleanly with the existing SELF segment structures because old coreboots will reject any segment type they don't recognize. We could say "take the 32-bit entry point + 0x200" but that's pretty hacky and then we still need to be able to mark the payload as 64-bit supporting somehow. We can't use a CBFS type for that either without breaking backwards-compatibility, so the only options I see would be using a CBFS attribute (which seems much less suitable than the type for this) or putting some kind of parseable header into the payload.
Both of them (and the "second entry point at hardcoded offset" thing) seem like really hacky and roundabout solutions for things that our data structures could represent in a much cleaner and more natural way (e.g. 64-bit payload as different CBFS type, or second entry point as SELF segment), that we'd only pick in the name of backwards-compatibility. I'd really prefer if we didn't need to make our handoff API so weird and unintuitive forever after only to avoid this one break in old-coreboot-new-libpayload compatibility (like we had FMAP cache in 2019, or boot_media_params in 2015). I'd rather we do another one clean break now, pick the most natural and intuitive option to represent things, try to anticipate future needs (e.g. X86S) in that decision as best as possible, and maybe think about what else we can change in order to allow future API additions to go over smoother (e.g. rethink the decision to make selfload() abort on every segment it doesn't recognize).