Re: [PATCH 1/2] vfio/pci: Set up VFIO barmap before creating a DMABUF

[Matt Evans]

Hi Kevin, Alex,

On 17/04/2026 06:16, Tian, Kevin wrote:
> > From: Alex Williamson <alex@xxxxxxxxxxx>
> > Sent: Friday, April 17, 2026 6:44 AM
> >
> > On Wed, 15 Apr 2026 11:14:22 -0700
> > Matt Evans <mattev@xxxxxxxx> wrote:
> >
> > > A DMABUF exports access to BAR resources which need to be requested
> > > before the DMABUF is handed out.  Usually the resources are requested
> > > when setting up the barmap when the VFIO device fd is mmap()ed, but
> > > there's no guarantee that's done before a DMABUF is created.
> > >
> > > Set up the barmap (and so request resources) in the DMABUF-creation
> > > path.
> > >
> > > Fixes: 5d74781ebc86c ("vfio/pci: Add dma-buf export support for MMIO
> > regions")
> > > Signed-off-by: Matt Evans <mattev@xxxxxxxx>
> > > ---
> > >   drivers/vfio/pci/vfio_pci_dmabuf.c | 9 +++++++++
> > >   1 file changed, 9 insertions(+)
> > >
> > > diff --git a/drivers/vfio/pci/vfio_pci_dmabuf.c
> > b/drivers/vfio/pci/vfio_pci_dmabuf.c
> > > index 4ccaf3531e02..fefe7cf4256b 100644
> > > --- a/drivers/vfio/pci/vfio_pci_dmabuf.c
> > > +++ b/drivers/vfio/pci/vfio_pci_dmabuf.c
> > > @@ -272,6 +272,15 @@ int vfio_pci_core_feature_dma_buf(struct
> > vfio_pci_core_device *vdev, u32 flags,
> > >   		goto err_free_priv;
> > >   	}
> > >
> > > +	/*
> > > +	 * See comment in vfio_pci_core_mmap(); ensure PCI regions
> > > +	 * were requested before returning DMABUFs that reference
> > > +	 * them.  Barmap setup does this:
> > > +	 */
> > > +	ret = vfio_pci_core_setup_barmap(vdev, get_dma_buf.region_index);
> > > +	if (ret)
> > > +		goto err_free_phys;
> > > +
> > >   	priv->vdev = vdev;
> > >   	priv->nr_ranges = get_dma_buf.nr_ranges;
> > >   	priv->size = length;
> >
> > Wouldn't this get a lot easier if we just setup all the barmaps in
> > vfio_pci_core_enable(), conditional on pci_resource_len() just like we
> > use to filter in REGION_INFO?
> >
> > I don't recall if there's some reason we've avoid this so far, maybe
> > others can shout it out if they do.
>
> I don't remember too. probably just because it's not a wide requirement
> then was made in this on-demand approach...
>
> > We already tear them all down in vfio_pci_core_disable().  It would be
> > a small patch to add that, which we would mark as Fixes:, then a small
> > follow-up on top of that that removes any then redundant or unnecessary
> > callers (all of them).  Thoughts?  Thanks,
>
> Agree. then the next patch fixing the racing conditions is also not required.

Oh, if we can do it earlier it's all much cleaner, agreed.  I'd naively 
thought there was a reason it was done lazily.  One benefit is truly 
huge TB-scale BARs don't get ioremap()ed until actually used by 
userspace.  I can't think of a good usage example that relies on open 
performance.

If you say fine, then great:  Ignore these, and I'll post a new pair of 
patches doing that (...with a cover letter this time).


Thank you,


Matt