Attention is currently required from: David Hendricks, Julius Werner, Jérémy Compostella, Kapil Porwal, Nico Huber, Patrick Rudolph, Subrata Banik, Werner Zeh.
Arthur Heymans 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:
A. Use a specific CBFS attribute for the payload header based on the ELF architecture. […]
Reading MSRs which can indicate whether a system is in long mode, I think, can be done mode agnostic. So the payload entry of a 64bit payload can be written in way such that it works coming from both 32bit and 64bit mode coreboot, with just a few extra instructions. Switching mode from 32 to 64 bit is also pretty easy. So the handling both the X86S case and the exiting 32bit handoff with the same payload binary should be very doable with a clean design and not much technical depth. Putting the responsibility to go to 64bit mode and set up paging in the payload is both future proof and backwards compatible.
Is implementing that detection runtime at the payload entry point, changing modes 2 times (as it works right now) and limiting the payload address or at least entry point at which the payload runs to ranges below 4G, worth it in order to keep some backwards compatibility. In my opinion, yes. It simpler than new coreboot runtime code + cbfs(tool) code. Sidenote about compatibility: Chainloading is also a common feature. New CBFS attr/file/whathever requires changes in all payloads that support this. That's not desirable if it can be avoided.
About X86S where the payload is entered in long mode: We probably should separate that discussion about how the handoff looks like (e.g. expectations on paging).