Hi, > Following the feedback, RFC v2 keeps PCI enumeration and resource > assignment in firmware. QEMU only validates the user-provided fixed > BAR configuration and provides the required metadata to firmware > through the "etc/fixed-bars" fw_cfg file.
qemu already has vendor-specific pci capabilities. They are used to pass hints for the bridge window sizes of pci bridges (including pcie root ports) with hotplug support. See OvmfPkg/PciHotPlugInitDxe/ for the firmware side support. I'd strongly recommend to do the same for the fixed bars: Add a pci capability to pass that information. All the logic you have today to link the information in the fw_cfg file to the correct pci device is simply not needed any more then. > * fixed-bar=on on a PCIe root port marks its subordinate hierarchy for > fixed BAR placement. Every device with memory BARs in that hierarchy > must provide a complete pci-bars= configuration. Why is this needed? > * pci-bars=barN@<addr>[,barM@<addr>]... on a PCI endpoint specifies the > required address for each memory BAR. All memory BARs on the device > must have an explicitly assigned address. fixed-bar-<nr>=<addr> ? > On the firmware side, a new DXE driver, QemuFixedBarsDxe, installs > EFI_INCOMPATIBLE_PCI_DEVICE_SUPPORT_PROTOCOL before PciBusDxe starts. > When PciBusDxe calls CheckDevice() for a discovered PCI function, the > driver returns ACPI address descriptors with _MIF|_MAF set for fixed > BARs. Two small changes to PciBusDxe preserve these fixed addresses and > program them into the BAR registers during BAR programming. Expecting PciBusDxe respecting AddrRangeMin looks sensible to me ... > After PciEnumerationComplete, QemuFixedBarsDxe walks each fixed > root-port hierarchy and programs the bridge memory windows to cover > the fixed BAR ranges assigned to endpoint devices. ... but changing things after-the-fact in platform code is a complete non-starter. PciBusDxe needs to do that, i.e. take care that the bridge window assigned actually cover the fixed pci bars. take care, Gerd
