Re: [RFC PATCH v2 0/5] hw/pci, hw/arm/virt: fixed PCI BAR placement

[Tushar Dave <tdave@nvidia.com>]

On 8/31/2026 8:24 AM, Gerd Hoffmann wrote:
> On Thu, Aug 27, 2026 at 07:47:33AM -0600, Alex Williamson wrote:
>> On Thu, 27 Aug 2026 09:18:50 +0200
>> Gerd Hoffmann <kraxel@redhat.com> 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

Good point but the problem is CheckDevice()'s own signature, which is
fixed by UEFI PI spec (only passes
VendorId/DeviceId/RevisionId/SubsystemVendorId/SubsystemDeviceId). Even
though the path exists internally, the standard protocol interface
doesn't pass it to the callback. Therefore, we prepare the blob entries
in the same order PciBusDxe discovers devices, so matching by VID:DID
inherently works.

> 
>>>> * 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.

I looked at this again, and technically nothing actually needs the flag
to exist. The real reason I kept it is closer to a usability one; it's
meant to be a visible signal in the launch script itself, so anyone
reading or writing the qemu command line sees up front that every device
under that root port is expected to have pci-bars= configured, rather
than that requirement only surfacing as a runtime error if something's
missing.

I would be okay to drop it but that was the reasoning. Let me know.

> 
> 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?

VFIO GPA == HPA is the primary motivation, but I don't think fixed-bar
should be tied to VFIO or automatically derive guest addresses from the
host. For the VFIO use case, the admin can choose to specify the host
BAR addresses as the fixed-bar configuration to get GPA == HPA, but the
mechanism itself doesn't assume or enforce that -- the desired guest
layout isn't always just a copy of the host's, so having fixed-bar
auto-derive it on its own would be incorrect in some cases, not just
less general. The mechanism remains a generic way to explicitly specify
PCI BAR addresses.

> 
>>>> * 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'.

Fair point.

-device some-device,pci-bars=bar0@0x1000000000,bar1@0x2000000000

would become:

-device some-device,fixed-bar-0=0x1000000000,fixed-bar-1=0x2000000000

and, with the 'size' property type, the same addresses could also be
expressed as:

-device some-device,fixed-bar-0=64G,fixed-bar-1=128G

> 
> take care,
>   Gerd

Thanks.
-Tushar