Hi coreboot fellows,
after two years with the new resource allocator it's time again for some changes[1]. Much less invasive than last time, but again there will be changes in the pattern where resources are placed. So once more this may uncover bugs in case fixed resources are not reserved properly.
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.
Another reason are approaching changes to support multiple PCI host bridges and multiple resource windows per domain.
I digress... So everybody is invited to test the patch train. There is a new Kconfig option RESOURCE_ALLOCATION_TOP_DOWN. The default y should work fine, though in case of regressions it would be nice to have it tested with both settings.
Cheers, Nico
[1] https://review.coreboot.org/q/topic:allocator+status:open
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
-
Nico Huber