On Wednesday, February 23, 2011 02:15:44 pm Jesse Barnes wrote: > > But maybe using MCFG's bus numbers *is* the canonical way of getting > the max bus... I don't know what Windows does here, but I can imagine > that it exposes all these devices to various drivers. Perhaps they're > hidden so that earlier versions of Windows won't "yellow bang" the > unknown devices, while newer versions use MCFG. [I added linux-acpi to the cc: list.] MCFG is for communicating memory-mapped configuration space addresses. I don't see anything in the specs about getting bus numbers from it. I would think _CRS is the canonical way of getting bus ranges because: - PNP0A03/08 devices have _CRS indicating bus range [PCI Firmware 3.0, sec 4.3.2.1]. - PNP0A03 devices (PCI or PCI-X host bridges) need not support the enhanced configuration access mechanism, so wouldn't need MCFG, but we still need the bus range. - DIG64 systems may have PNP0A08 devices but no MCFG, but again, we still need the bus range [PCI Firmware 3.0, sec. 4.1.5]. > Does anyone have an affected machine with Windows 7 or something so we > can verify? If we added MCFG support to qemu, it should be pretty easy to see how Windows handles it, but I'm not in a position to do that right now. Bjorn -- To unsubscribe from this list: send the line "unsubscribe linux-pci" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html