x86 PCI enumeration should not rely on bios max bus
Traditionally, on an x86 BIOS based system, we rely on the PCI BIOS specification which has a series of BIOS calls one can make to determine information about the PCI devices in the system. One of these values is supposed to contain the maximum PCI bus number that should be scanned for devices.
Unfortunately, we've found many cases where this information is wrong. In particular, I discovered this is the case for all of the SMCI Richmond, Tenderloin, and Hallasan systems. On these systems we were only seeing one socket's worth of built-in PCI devices from the 'uncore'. This made me very suspicious. Many other systems have the second socket's PCI bus as 0xff. However, the value of pci_bios_maxbus was much lower! Using kmdb, I confirmed my suspicion:
> pci_bios_maxbus/D pci_bios_maxbus: pci_bios_maxbus:134 > 0::rdpcicfg 0xff 0t19 0 6fa88086
So clearly, the BIOS is lying here. We actually have a device that's above the max bus. While we should probably still trust it to determine what mechanism we're using. We're going to instead just treat the max bus like the EFI case and just scan all of them.
This has been tested on a number of different platforms in conjunction with 11609. These include:
- Sandy Bridge 2s
- Ivy Bridge 2s
- Haswell 1s/2s
- Broadwell 2s
- Skylake 2s
- Cascade Lake 2s
- Kaby Lake NUC
- Coffee Lake Desktop system
- AMD EPYC system