On 25.06.22 22:05, Nico Huber wrote:
> Reasons for the changes are somewhat the same as always: we haven't
> finished the support for 64-bit resources. Currently one has to opt
> in for a placement above 4G with a resource flag, and even this has
> its limitations. For instance, reserved space for hot-pluggable de-
> vices can be placed above 4G with a Kconfig setting, but there's no
> rule what should happen with the resources of cold-plugged devices.
> In the worst case, allocation for those can fail.
After some discussions on IRC, a potential default solution started
to shape itself. The goal is to have a common, still simple scheme
that doesn't run out of resources easily, but also allows to boot
with 32-bit coreboot and payloads, so:
Place every prefetchable resource above 4G that supports it,
except optionally the resources of the primary VGA device.
For prefetchable resources of hotpluggable devices, this is already
the default.
The primary VGA device usually has its framebuffer in a prefetchable
resource. It is required below 4G for access from 32-bit coreboot and
32-bit payloads. However, on some platforms like servers, it's infea-
sible to have it below 4G due to space constraints. So this would de-
finitely require a Kconfig, probably with a prompt and default n for
server platforms.
That's so far the bare minimum I expect we would need. Additional
Kconfig options are imaginable. However, I would prefer to add as
few as possible. For better compatibility with 32-bit payloads:
* Opt-out for everything "onboard".
* Opt-outs for other device classes that one might want to boot from
in 32-bit mode:
- Storage (RAID controllers mostly)
- Network
Note, these can have, but often don't have prefetchable resources.
* Alternatively to opt-out options, an option for additional allocator
rounds that try to move resources from above 4G to below 4G (poten-
tially with a priority based on the device class).
If somebody wants to keep the current behavior, the following, but
please speak up early(!) as this would make the code more complex:
* An option to keep the current default to place resources only
above 4G on request. If we add this, we would also
- keep the current PCIEXP_HOTPLUG_PREFETCH_MEM_ABOVE_4G, and
- potentially extend it to cover everything behind a
hot-pluggable port explicitly (currently that's implied by
the implementation, but not documented).
Nico
_______________________________________________
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org
