Attention is currently required from: Arthur Heymans, Julius Werner, Jérémy Compostella, Kapil Porwal, Nico Huber.
2 comments:
Patchset:
Subrata, please slow down. It's not just about implementing it and making it
work. coreboot and the payload should be independent and interchangeable. If
you want to create a 64-bit payload that can't be loaded by a current core-
boot (or one from the release branches?) for no obvious reason, that's ok, but
then you don't have to do it upstream. I would rather see it upstream, though.
Adding a 64-bit ABI and handover is something we have to do anyway, for X86S.
So any effort in that direction would be really appreciated, as long as we
don't unnecessarily sarcifice compatibility.The last handover convention worked for what? 20 years, maybe? Please see that
as a goal for a 64-bit version. We should design and discuss something that can
last 20 years without binary incompatibilities. And then implement it. In the
mean time, you can use the old convention as long as your CPU supports protected
mode.Beside strengthening the ecosystem, compatibility is also good for other reasons.
For instance, when someone debugs a regression and doesn't know if the problem
is in the payload or in coreboot. In the past it was usually possible to try
a new coreboot with an old payload build and vice versa.
Nico, I totally agree with you that this support has to be added such a way that we can maintain the code for next several year. But there has to be start point and I'm starting that as I have to ensure 64-bit support in AP FW.
I don't understand where are you seeing the below issues
1. compatibility are broken
2. ABI are not stable
yes, we can't achieve everything overnight but when someone is willing to put the energy and implementing supporting why so much back and forth communication. Give the feedback to improve the code and please don't say, "slow down".
if you wish we don't work in upstream that is a feedback which we would like to consider. I felt the community was not aware that 64-bit support will knock our door one day and we don't have answer to that question.
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?
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.
Why do you need that without trunking? Are you talking about HW that does not have 32bit support
[Subrata] Intel's claims about next generation SoC is legacy free like 64-bit is only supported.
or do you want to load/jump to the payload above 4G?
[Subrata] This depends on the memory layout for the target platform. if we don't see any free/available memory < 4GB then jumping to 64-bit mode is only option.
> 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 we decide on a multiple entry point approach, then you end up with 2 ways: one with multiple entry points and one with an attribute indicating in which mode the payload works. That's 2 ways to do the same and since ABI needs to be stable that's not a good situation.
[Subrata] I don't under why all of sudden the "multiple entry point approach" considered critical. The problem of supporting 64-bit direct entry can be handled w/o that as well. Having multiple entry point approach like kernel may not be that critical at this stage. we can jump into 64-bit entry point using boot.c code (CB:81960). For that we don't need to support multiple entry point approach. If you wish to implement multiple entry point approach, please do that w/o blocking the current task is my request.
> 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.
>Improving probably means breaking an ABI compatibility in the future. That's not a good idea.
[Subrata] I don't understand what makes you feel that any improvement means breaking things. We can make this approach of CBFS attribute deprecated as and when the multiple entry point approach is ready. multiple entry point approach can be designed such way that it won't cause any issue in existing 32bit/64bit entry call.
> 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.The unified payload stuff indeed should not trump your business needs and I'm not suggesting to wait for that to happen. However I do think that thoughtful design and discussion needs to happen around the introduction of a ABI, before moving forward. In my opinion that should be a priority before merging something that works.
[Subrata] I don't follow why you need to introduce a new ABI. The 64-bit calling convention is defined and as mentioned the x86_64 libpayload work has also completed where we are able to jump into head.S in 64-bit.
Sorry, I might be missing but are you suggesting to implement 64-bit libpayload before implementing the long mode entry code ?
To view, visit change 81960. To unsubscribe, or for help writing mail filters, visit settings.