Attention is currently required from: Julius Werner, Jérémy Compostella, Kapil Porwal, Nico Huber, Subrata Banik.
1 comment:
File src/arch/x86/boot.c:
Patch Set #1, Line 25: if (CONFIG(PAYLOAD_X86_64_SUPPORT)) {
Would it be possible to make it an offset? Then we could have a 32-bit entry
point followed by a 64-bit one, and a coreboot that knows the new ABI could skip
the first and jump directly to the new entry point. This would allow the most
compatibility between coreboot and payloads, as we could say the 64-bit entry
point is optional on both ends (except for X86S, ofc.).I guess the complexity of such a 32-bit entry point, that switches to long mode,
would depend a lot on the expectations on page tables in the new ABI.I guess a minimal expectation of at least 4G identity mapped is reasonable. Iirc UPL does that too. I like the idea of multiple entry points over a CBFS attribute as it's indeed the best way to be remain compatible. Linux already has exactly this btw. Question remains on how to achieve this? Have an expectation on the namespace in the ELF file which cbfstool can pick up? .text._entry64?
can we review CB:81964 that adds the payload cbfs attribute for 64-bit. Then this CL has now updated to fetch the cbfs attribute rather reading any static Kconfig.
following kernel concurrent 32-bit and 64-bit entry implementation may not be desired in AP FW as out configuration are very much static. We have to anyway select Kconfig in SoC to know if we are building 32-bit coreboot vs 64-bit coreboot hence, rather than complicating the flow, not sure what else we will bring by adding kernel like implementation while transferring control from coreboot to payload.
My previous comment explained that building coreboot and payload together is not the only way of doing things and should not be assumed... Entering 64bit mode from in the payload itself with a 32bit entry point can be done in 12 instructions. That's not too complicated and should be considered with the dual entry point strategy.
Anyway, lets review this CL to ensure we have atleast some ways to launch 64-bit payload from a 64-bit coreboot w/o lowering into 32-bit mode. Later we can desire more scalable approach for handoff. btw, i will bring x64 support cls next for libpayload.
Let's not rush this. An ABI needs to be well designed and well documented. I don't think the fix/improve later approach is good here, as it implies breaking the ABI that worked at some point. If you want a 64bit libpayload, maybe start with a 32bit entry point that jumps to 64bit, which should work as is. In the meanwhile let's have a discussion on the ML on what the ABI would look like?
To view, visit change 81960. To unsubscribe, or for help writing mail filters, visit settings.