Hi Kevin, On 12/06/2026 09:27, Tian, Kevin wrote: >> From: Matt Evans <[email protected]> >> 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
