Re: [PATCH v3 0/9] vfio/pci: Add mmap() for DMABUFs

[Matt Evans]

Hi Kevin,

On 12/06/2026 09:27, Tian, Kevin wrote:
>> From: Matt Evans <matt@xxxxxxxxxx>
>> Sent: Wednesday, June 10, 2026 11:43 PM
>>
> [...]
>>
>>  vfio/pci: Support mmap() of a VFIO DMABUF
>>
>>    Adds mmap() for a DMABUF fd exported from vfio-pci.
>>
>>    It was a goal to keep the VFIO device fd lifetime behaviour
>>    unchanged with respect to the DMABUFs.  An application can close
>>    all device fds, and this will revoke/clean up all DMABUFs; no
>>    mappings or other access can be performed now.  When enabling
>>    mmap() of the DMABUFs, this means access through the VMA is also
>>    revoked.  This complicates the fault handler because whilst the
>>    DMABUF exists, it has no guarantee that the corresponding VFIO
>>    device is still alive.  Adds synchronisation ensuring the vdev is
>>    available before vdev->memory_lock is touched; this holds the
>>    device registration so that even if the buffer has been cleaned up,
>>    vdev hasn't been freed and so the lock can be safely taken.
>>
>>    This commit makes VFIO_PCI_CORE depend on PCI_P2PDMA_CORE
>> (commit
>>    1) to bring in (only) the P2PDMA provider code.
> 
> the last sentence is stale as the dependency is now added in patch4.

Right, will fix.

>>
>> End
>> ===
>>
>> This is based on VFIO next (e.g. at b9285405c5f6).
>>
> 
> Sashiko failed to apply this series. Is there dependent work in vfio-next?
> 
> otherwise getting a Sashiko review is helpful here.

It _did_ depend on (at least the context of) some fixes in vfio-next.
Looks like it'll rebase on master now those are merged.  I should've
re-checked this for v3, oops. :|

(FWIW, I had Robot Claude Opus 4.8 to review several times up to v3.
But I agree, Sashiko would be interesting too.  Can it be manually
triggered with branch guidance?)


Thanks,


Matt