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

[Matt Evans <mattev@meta.com>]

Hi,

On 17/04/2026 20:11, Matt Evans wrote:
> 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).

New series posted:

https://lore.kernel.org/kvm/20260421174143.3883579-1-mattev@meta.com/

(Titles/semantics very different, so didn't send as a v2 of this.)


Matt