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

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:

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.

* 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,

[1] https://review.coreboot.org/c/coreboot/+/81960

(*) 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-
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-leave@coreboot.org