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

[Matt Evans <mattev@meta.com>]

Hi Kevin, Alex,

On 17/04/2026 06:16, Tian, Kevin wrote:
> 
>> From: Alex Williamson <alex@shazbot.org>
>> Sent: Friday, April 17, 2026 6:44 AM
>>
>> On Wed, 15 Apr 2026 11:14:22 -0700
>> Matt Evans <mattev@meta.com> 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@meta.com>
>>> ---
>>>   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