Dear Bin,
Thank you very much for your patches.
Am 01.01.21 um 04:08 schrieb Bin Gao:
On real hardware especially server platforms, there might be multiple
Please give a concrete example of the hardware.
All Intel server processors have multiple PCI roots, called IIO.
root buses, thus pci bus number could run up to 255. This patch fixed
Nit: I’d use present tense in commit messages: This patch fixes ….
pci_probe_devices() by allowing to scan all 256 pci bus numbers(0-255).
Nit: Space before (.
Will fix this (and tense) in next revision.
Signed-off-by: Bin Gao gaobin@amazon.com
src/hw/pcidevice.c | 8 ++++++++ 1 file changed, 8 insertions(+)
diff --git a/src/hw/pcidevice.c b/src/hw/pcidevice.c index 8853cf7..8d9c401 100644 --- a/src/hw/pcidevice.c +++ b/src/hw/pcidevice.c @@ -26,6 +26,14 @@ pci_probe_devices(void) struct hlist_node **pprev = &PCIDevices.first; int extraroots = romfile_loadint("etc/extra-pci-roots", 0); int bus = -1, lastbus = 0, rootbuses = 0, count=0;
- // There might be multiple PCI root buses on physical hardware especially
- // server platforms, thus bus number could run up to the top value,
- // i.e. 0xff. Setting extraroots to 0xff to ensure we can enumerate all
- // PCI bus numbers.
- if (CONFIG_CSM)
extraroots = 0xff;Can there be a romfile with CSM? If yes, the configured value would be overwritten. Maybe add a log message in that case?
There is no romfile with CSM. I do think the correct fix is to scan all the PCI buses, instead of to get a default max bus number. The fact is, on physical hardware, we can't assume the max bus number. On typical server design, it easily consumes up all the bus numbers, e.g. some PCIe bridges could pad up with many buses. On Intel server processors, for instance, we may want to split the 256 bus number to all IIOs so it's almost sure that we can reach up the maximal possible bus number (in a single PC segment). Yes, I can add a log message in that case.
while (bus < 0xff && (bus < MaxPCIBus || rootbuses < extraroots)) { bus++; int bdf;Kind regards,
Paul