Re: [PATCH v2 1/2] vfio/pci: fall back to platform ROM when pci_map_rom() fails

[Alex Williamson <alex@shazbot.org>]

On Wed, 11 Nov 2026 06:02:35 -0500
"Michael S. Tsirkin" <mst@redhat.com> wrote:

> On Tue, Nov 10, 2026 at 04:52:21PM -0700, Alex Williamson wrote:
> > On Wed, 21 Oct 2026 04:20:32 -0400
> > "Michael S. Tsirkin" <mst@redhat.com> wrote:
> >   
> > > When pci_resource_start() returns non-zero but pci_map_rom() fails
> > > (ROM BAR exists but content is unreadable), the pdev->rom fallback
> > > is unreachable because it's behind an else-if that only triggers
> > > when pci_resource_start() is zero.
> > > 
> > > Try pdev->rom whenever the ROM BAR didn't produce a mapping, in both
> > > the region info ioctl and the read path.  
> > 
> > Here's the crazy thing, users actually update firmware through
> > vfio-pci.  Therefore, what's an invalid ROM image on one check, may be
> > a valid ROM image next round.  If we fall through to a different ROM
> > provider, we might actually be presenting a changing view of the
> > device.  
> 
> 
> This is out of spec anyway. The spec is pretty clear that _ROM if
> present takes precedence over the ROM BAR.  I decided not to change that
> if ROM BAR is valid to reduce the chance of breaking a working setup.
> 
> From ACPI 6.3, Section A.3.3 "_ROM (Get ROM Data)", page 1123:
> 
> 	If _ROM is present, it is preferred over the image read through the
> 	standard PCI interface, in order to allow platform runtime firmware to
> 	provide re-configured ROM data via the method.
> 
> 
> Would you like me to simply implement the spec? Use _ROM if there
> even if pci rom bar is valid?

The spec goes on to state:

	This method is defined to provide this data as motherboard
	devices typically don’t have a dedicated option ROM.

Your use case falls within the guidance and fits within our existing
fall through model to look for alternate options only if the ROM BAR is
not present or mapped.

A "preference" is also not a mandate that we need to virtualize _ROM as
a ROM BAR.  We fall through to other sources for convenience.  A
cleaner approach might be to expose _ROM as a device specific region
(same with pdev->rom), allowing the VMM to decide how to expose it,
virtualizing the ROM BAR, a BIOS ROM slot, or ACPI _ROM method.

It seems a bit overkill to implement that though when the example
device we're enabling and the spec, both favor that the ROM BAR is
likely not present.  The fall through seems the more conservative
approach that also handles every known case.

> > I believe this is why we intentionally always report the physical ROM
> > BAR when present and mapped, regardless of the contents.  
> 
> No such setups should have _ROM, since rombar would then be ignored.
> 
> > QEMU, of course, has the ability to take the ROM as a file and override
> > whatever is provided through the kernel interface.  This is how I had
> > previously made use of a secondary GPU on a laptop, dumping the ACPI
> > ROM to a file to provide directly to QEMU.  
> 
> First we need a way to get the ROM from _ROM.
> 
> > 
> > Does your GPU support a ROM BAR?  The v1 patch didn't have this and
> > would have exposed the physical RAM BAR if present, so I'm guessing not.
> > Thanks,
> > 
> > Alex  
> 
> It has a bar but it is not accessible. _ROM overrides that, as per spec, and this
> appears to be how nvidia drivers use it and expect to use it.

Without an example where we have both a programmed ROM BAR and a _ROM
method, I'm not inclined to risk changing from one ROM image to another
for existing users.  Allowing the VMM to pick a policy probably means
exposing _ROM via a device specific region.  Thanks,

Alex