Attention is currently required from: Arthur Heymans, Julius Werner, Jérémy Compostella, Kapil Porwal, Nico Huber.
Subrata Banik 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 2:
(1 comment)
File src/arch/x86/boot.c:
https://review.coreboot.org/c/coreboot/+/81960/comment/d6a9228d_74189f02 : PS1, 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?
I respectfully disagree with your approach.
The problem statement is straightforward:
coreboot currently always enters payload/libpayload in 32-bit mode, even when Coreboot is built natively for 64-bit mode. As explained, we need to ensure that we have support for 64-bit direct entry without trunking.
I agree with you that we should add things to the payload CBFS to make things dynamic so that Coreboot can decide to jump either directly into 64-bit mode or fall back to 32-bit.
I am not sure what is being broken by this approach. We are enabling 64-bit mode for payload and testing it seamlessly in parallel to 32-bit entry.
If you wish to improve how the entry point should be handled in the future, that can be done separately. I am not sure why I need to hold off my activity or do things by your means.
As I stated earlier, I will provide the libpayload 64-bit support code so you can examine how the entry point would appear. I ask that you do not combine this effort with unified payload. Unified payload is still in the planning stages, but enabling 64-bit support in coreboot/payload has business value; thus, the priority should not be the same at your end as it is at mine.