Hi coreboot fellows,
yesterday some patches[1] surfaced on Gerrit about a handover for 64-bit x86 payloads. Strictly speaking, we don't have to do anything for this right now, as the original, protected-mode handover would work too. How- ever, there is X86S on the horizon. If you don't know about it, here is the short version: X86S was announced by Intel last year, it's supposed to be a simplified version of AMD64, without real nor protected mode, so 64-bit long mode only. So we have:
+----------------+-------+------+ | | AMD64 | X86S | +----------------+-------+------+ | real mode | X | | +----------------+-------+------+ | protected mode | X | | +----------------+-------+------+ | long mode | X | X | +----------------+-------+------+
After a night's sleep, I'm convinced we should keep things as simple as possible on the coreboot side, and hence propose the following:
1. AMD64: Keep the current, 32-bit protected mode handover 2. X86S: Hand over in long mode with a) the pointer to cbtables in RDI (like the first parameter in the System V ABI), b) the guarantee that the payload and cbtables are identity mapped in the current page tables.
Rationale: * 1. Allows us to keep compatibility where it's possible. X86S breaks compatibility on purpose but we don't have to break compatibility in the AMD64 case. There is one exception: A future X86S payload could potentially run on AMD64 and vice versa. Though, compatibility could be ensured on the payload end (e.g. having two entry points like the Linux kernel has(*)). * Keeping the current handover where possible would allow to use a new 64-bit payload with a coreboot build from one of the older branches, for instance, without having to modify them all. Existing coreboot binaries for AMD64 systems would stay compatible as well. * 1. requires a 64-bit payload to switch (back) to long mode by itself. This should be straight-forward, though, and can be done with rather few instructions. The necessary page-table setup could be kept small, as long mode supports 1GiB pages. Having to set up its own page ta- tables also avoids problems with assumptions about the prior setup. * Generally, we can't control what downstream does. However, by adding a long-mode handover as late as possible (i.e. the first X86S port), we would encourage everybody to stay compatible. Once the long-mode handover is implemented upstream, it will be easier to create a pay- load that works with some x86 coreboot builds, but not all. Making it X86S only, will limit the room for incompatibility. * 2. a) is probably what people would expect. * 2. b) allows for more flexibility in coreboot, without having to set up much (ideally nothing) special for the payload. If we'd make more guarantees, e.g. a whole 4GiB space identity mapped, it would become more likely that we have to change the mapping for the handover. For instance, if we'd ever decide to add a continuous mapping for a >16M flash chip. That would likely still be compatible with 2. b), though might not be with more elaborate guarantees.
So, please share your thoughts :)
Best regards, Nico
[1] https://review.coreboot.org/c/coreboot/+/81960 https://review.coreboot.org/c/coreboot/+/81964 https://review.coreboot.org/c/coreboot/+/81968
(*) All payloads (builds) until now will be incompatible to X86S. But if we'd encourage to give all 64-bit payloads from now on two en- try points (32- and 64-bit), we could increase the number of pay- loads that are both compatible to X86S and all prior AMD64 core- coreboots.
Hi
So to play devil's advocate on why having a 64bit payload handoff/entry point on AMD64 might be desirable: - speed (how long does the mode transition take?) - flexibility: loading and jumping to it above 4G
However I'm not convinced by either argument and I agree with your proposal. It's keeping things compatible and simple on the coreboot side (no change or runtime detection) and requires only a bit more logic on the payload side.
https://review.coreboot.org/c/coreboot/+/82016 adds that 32bit entry point for 64bit libpayload. I'll try to make it work in the next few days. As this requires no changes in the coreboot handoff and still allows to have the benefits of a 64bit payload (except the location of the entry point), I think it's a solid way forward. Unless I'm wrong about the arguments I gave first not being valid.
Kind regards Arthur
On Fri, Apr 19, 2024 at 2:01 PM Nico Huber via coreboot < coreboot@coreboot.org> wrote:
Hi coreboot fellows,
yesterday some patches[1] surfaced on Gerrit about a handover for 64-bit x86 payloads. Strictly speaking, we don't have to do anything for this right now, as the original, protected-mode handover would work too. How- ever, there is X86S on the horizon. If you don't know about it, here is the short version: X86S was announced by Intel last year, it's supposed to be a simplified version of AMD64, without real nor protected mode, so 64-bit long mode only. So we have:
+----------------+-------+------+ | | AMD64 | X86S | +----------------+-------+------+ | real mode | X | | +----------------+-------+------+ | protected mode | X | | +----------------+-------+------+ | long mode | X | X | +----------------+-------+------+After a night's sleep, I'm convinced we should keep things as simple as possible on the coreboot side, and hence propose the following:
- AMD64: Keep the current, 32-bit protected mode handover
- X86S: Hand over in long mode with a) the pointer to cbtables in RDI (like the first parameter in the System V ABI), b) the guarantee that the payload and cbtables are identity mapped in the current page tables.
Rationale:
compatibility on purpose but we don't have to break compatibility in the AMD64 case. There is one exception: A future X86S payload could potentially run on AMD64 and vice versa. Though, compatibility could be ensured on the payload end (e.g. having two entry points like the Linux kernel has(*)).
- Allows us to keep compatibility where it's possible. X86S breaks
- Keeping the current handover where possible would allow to use a new 64-bit payload with a coreboot build from one of the older branches, for instance, without having to modify them all. Existing coreboot binaries for AMD64 systems would stay compatible as well.
This should be straight-forward, though, and can be done with rather few instructions. The necessary page-table setup could be kept small, as long mode supports 1GiB pages. Having to set up its own page ta- tables also avoids problems with assumptions about the prior setup.
- requires a 64-bit payload to switch (back) to long mode by itself.
- Generally, we can't control what downstream does. However, by adding a long-mode handover as late as possible (i.e. the first X86S port), we would encourage everybody to stay compatible. Once the long-mode handover is implemented upstream, it will be easier to create a pay- load that works with some x86 coreboot builds, but not all. Making it X86S only, will limit the room for incompatibility.
- a) is probably what people would expect.
up much (ideally nothing) special for the payload. If we'd make more guarantees, e.g. a whole 4GiB space identity mapped, it would become more likely that we have to change the mapping for the handover. For instance, if we'd ever decide to add a continuous mapping for a >16M flash chip. That would likely still be compatible with 2. b), though might not be with more elaborate guarantees.
- b) allows for more flexibility in coreboot, without having to set
So, please share your thoughts :)
Best regards, Nico
[1] https://review.coreboot.org/c/coreboot/+/81960 https://review.coreboot.org/c/coreboot/+/81964 https://review.coreboot.org/c/coreboot/+/81968
(*) All payloads (builds) until now will be incompatible to X86S. But if we'd encourage to give all 64-bit payloads from now on two en- try points (32- and 64-bit), we could increase the number of pay- loads that are both compatible to X86S and all prior AMD64 core- coreboots. _______________________________________________ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-leave@coreboot.org
-
Arthur Heymans -
Nico Huber