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.
_______________________________________________
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org
