On Thu, 27 Aug 2026 09:18:50 +0200 Gerd Hoffmann <[email protected]> wrote:
> 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. Placement of a VMM defined capability into a vfio-pci device is not such a trivial problem as it is for emulated devices. Space may not be readily available and the capability may mask non-architected registers. Does this suggestion relate to fixing the gap between mapping fw_cfg entries by vendor/device IDs or is there something fundamentally undesirable about using fw_cfg here? > > * 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? AIUI, the problem space is greatly expanded if we mix user provided fixed-bars with firmware assigned BARs and it's possible that there is no solution that meets the requirements. This option both simplifies the problem space and allows the resource windows to be audited to generate user actionable errors in QEMU. > > * 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> ? Could be a reasonable alternative. I'll let Tushar or others wrestle with the deeper edk2 comments below ;) Thanks, Alex > > 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 > >
