Attention is currently required from: Arthur Heymans, Julius Werner, Jérémy Compostella, Kapil Porwal, Patrick Rudolph, Subrata Banik, Werner Zeh.
1 comment:
Patchset:
Thanks for your thoughts, Julius.
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).
That particular example is good know. I'm not sure but I might actually hit
that incompatibility soon.
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),
Absolutely, yes. Hence my email.
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.
Yeah, I trust you when you say it would be too messy, you're definitely more
experienced with this CBFS than I am. I thought about the dual-entry solution
more as a nice to have anyway, to increase compatibility. And assumed that we
could leave most of the added complexity to the payload. e.g. with an attribute
```
if (has 64-bit attribute)
jump where the attribute says
else
die
```
for X86S. And for AMD64 just keep the current code. That was my naive idea
without considering the overall payload loading. IIUC, you are saying that
it would be cleaner if we had a separate type that we would check anyway
before loading? And you are in favor of a new CBFS type (not a new segment
type), is that correct?
Dual entry aside, do we already have code in coreboot that considers archi-
tecture-specific types or would we have to add code?
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).
We definitely can agree on the clean break, however not when it should happen,
now vs. the first X86S platform. I don't want to repeat my whole email here,
my basic thought was how we could do it with minimal (or no) additional com-
plexity in coreboot. And preferably the least `if`s in coreboot and payload
build systems. If we do the long-mode handover now before X86S, we have to
answer more questions, e.g.
On X86S that combination fails by definition, so less questions to answer.
I thought the simplest possible solution is to treat X86S like a seperate
architecture. Then we would simply imply to do a 64-bit handover on X86S
just like we imply to do things the ARMv8 way on ARMv8 etc. On AMD64 we
could keep the 32-bit handover because we already chose that in the past.
Would that need a new CBFS type?
To view, visit change 81960. To unsubscribe, or for help writing mail filters, visit settings.