On Fri, Jun 12, 2026 at 04:11:50PM +0100, Matt Evans wrote:

Hi Kevin,

On 12/06/2026 09:27, Tian, Kevin wrote:

...

...

From: Matt Evans matt@ozlabs.org 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?)

I guess relevant steps to run locally are here: https://github.com/sashiko-dev/sashiko/blob/main/README.md

Additionally, we can try providing a base-commit (which points to a public commit).

Thanks, Praan