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-leave@coreboot.org