Bug #14558


pci resource allocation should not be worst fit

Added by Robert Mustacchi 5 months ago.

Start date:
Due date:
% Done:


Estimated time:
Gerrit CR:


There are several problems with the initial resource allocation in pci_boot.c. It very much relies upon system firmware (e.g. UEFI/BIOS) performing the traditional role of the PCI firmware specification. In particular, if we end up in the case where we need to reprogram things, there are several sets of problems here, not limited to:

  • We do not handle the case here where any PCI bus is not assigned as the subordinate bus to a bridge. The system very much assumes that this part of the PCI firmware spec has been executed. If it has not, then we simply blow up rather than attempt to actually do bus assignment here.
  • When reprogramming memory, things here don't work very well when there are complex alignments. When allocating PCI resources, we go through and attempt to align the address to its requested length. e.g. a 16 MiB allocation needs 16 MiB alignment. However, the system does not actually take this into account when performing allocations. It appears that the hotplug variant might somewhat via the PCICFG_ROUND_UP macro (e.g. in pcicfg_sum_resources).

The hotplug code on the other hand also doesn't handle 64-bit addresses and related. Ultimately, in the spirit of IPD 21 this is something that needs to be revisited and unified between the different implementations and then ultimately shared across all platforms so we only have this done once. We need to take into account various parts of PCI-PCI bridges, NTBs, etc.

Such an implementation should probably be smart enough to be able to do a better fit here, potentially determining if it can use 64-bit addressing or not and preferring that where we have much more available address space. This would require refactoring quite a lot of how the implementation works. Part of the challenge and the reason for disparate things over the years is that pci_boot uses ACPI to seed more traditional IEEE 1275 style information around regs, assigned addresses, ranges, etc. and then the pcicfg on x86 consumes all that.

We likely need to work in a hybrid world where our first pass is setting up that information and taking information that has already been set up by systems firmware but then using this throughout the rest of PCI configuration. This will likely be aided by memlist unification.

No data to display


Also available in: Atom PDF