missing MCFG table should lead to I/O PCIe config access
I have a machine with some firmware that is somewhat less than ideal: it does not pass an ACPI MCFG table to the operating system. This leaves us with no earthly notion of the base address for memory-mapped access to PCI Express configuration space.
There are various places in the code where we use a hard-coded default value (0xE0000000); where this value came from, I have no idea. It is not clear that a PCI Express system can legitimately omit the MCFG table and still expect the OS to do MMIO for configuration space access.
In npe_bus_map(), we look up the "ecfg" DDI property for the bus; if missing, we disable MMIO access to configuration space. Sadly, in npe_query_acpi_mcfg(), we unconditionally set this same property to the hard-coded default: the fallback code will never take effect.
We make the same apparent error again in another routine. If fakebop was able to find an MCFG ACPI table, it will populate mcfg_mem_base with an appropriate value; this happens in process_mcfg() and is consumed in pci_check(). When we get to pci_setup_tree(), if mcfg_mem_base has not been set, then we once again assume (via, it must be said, a separate hard-coded copy) the magic number 0xE0000000.
I would essentially like to propose that we stop making up numbers, and trust the system to either tell us where the address is, or give up and fall back to I/O access to configuration space. I'm also open to somebody with access to relevant standards documents explaining where the magic number 0xE0000000 comes from, if anywhere – the "PCI Express Firmware Specification" is probably relevant here, but it is tough to know without a copy.
In June 2015, I sent mail to the mailing list with the subject "ACPI MCFG Tables and You". In response to this mail, I receive a large number of survey responses from illumos users about their systems. From the results, it is reasonably clear that 0xE0000000 is a common PCIe MCFG base address, but is absolutely not true of every system. Assuming the methodology is sound (looking at the properties of /devices with prtconf -v), I was also not aware of any other systems that are missing MCFG tables.
I also reached out to the CoreBoot developers of the problematic BIOS, and they were possibly already aware of (and will hopefully eventually fix) the deficiency in the firmware.
This change seems relatively low risk, given the systems we (and others) have seen in the wild.
Updated by Electric Monk about 5 years ago
- Status changed from New to Closed
commit 99abc82310f6fbd4f04276f195f54d54f458be33 Author: Joshua M. Clulow <firstname.lastname@example.org> Date: 2016-05-09T16:51:38.000Z 6859 missing MCFG table should lead to I/O PCIe config access Reviewed by: Robert Mustacchi <email@example.com> Reviewed by: Dan McDonald <firstname.lastname@example.org> Reviewed by: Tycho Nightingale <email@example.com> Reviewed by: Garrett D'Amore <firstname.lastname@example.org> Approved by: Gordon Ross <email@example.com>