On Thu, Aug 27, 2026 at 07:47:33AM -0600, Alex Williamson wrote:
> On Thu, 27 Aug 2026 09:18:50 +0200
> Gerd Hoffmann <[email protected]> wrote:
>
> > 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?
Well, fw_cfg is the fallback option if we don't have any better way.
Attaching the information directly to the device by placing it in a
pci capability is at very minimum worth exploring. If this is not
working for vfio devices, ok, we have to accept that I guess.
And, yes, the logic to match entries in the fw_cfg file with the correct
device using vendor and device id looks somewhat fragile to me too.
Existing code in qemu+firmware (for example bootorder) uses the location
in the physical device tree to identify devices, like this:
/pci@i0cf8/pci-bridge@3/*@0/*@0/*@0,0
^^^^^^^^^ pcie root bus
^^^^^^^^^^^^ pcie root port @ slot 3
^^^ virtio-scsi-pci @ slot 0
^^^ scsi controller bus #0
^^^^^ scsi device target 0, lun 0
> > > * 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.
I can see that allowing fixed and non-fixed bars mix is much harder to
handle. Do we need to ask the user to manually set that though? I'd
prefer pci devices propagating automatically to the parent bus that they
have fixed bars and additional constrains apply.
Also: if the main use case for this is to map vfio devices with guest
physical address == host physical address, is there a need to specify
this manually at all? Shouldn't we have a 'vfio-pci-fixed' device which
handles this automatically?
> > > * 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.
Parsing (and quoting) property strings with commas in the middle is a
PITA, also when using numerical properties you can use the 'size'
property type which accepts things like '16G'.
take care,
Gerd
