On Tue, 6 Oct 2026 20:36:36 +0100 Matt Evans matt@ozlabs.org wrote:
A VFIO DMABUF can export a subset of a BAR to userspace by fd; add support for mmap() of this fd. This provides another route for a process to map BARs, in which the process can only map a specific subset of a BAR represented by the exported DMABUF.
mmap() support enables userspace drivers to safely delegate BAR sub-ranges to other processes by sharing a DMABUF fd, without having to share the (omnipotent) VFIO device fd with them.
Since the main VFIO BAR mmap() is now DMABUF-aware, the new mmap() reuses the existing vm_ops.
The lifecycle of an exported DMABUF remains decoupled from that of the device fd it came from, i.e. the device fd could be closed with DMABUF VMAs present, meaning a fault on a VMA could happen concurrently with vfio_pci_dma_buf_cleanup().
To deal with this scenario, the fault handler now temporarily takes a VFIO device registration to ensure the vdev remains valid, and then vdev locks can be taken.
This sounds like potentially measurable overhead if something is slamming the fault handler where huge-fault is not supported or active. Have you considered a fast path for the internal dmabuf where the lifecycle is constrained?
Hopefully we can get those selftests included to avoid regressions.
Overall, I'm not finding too much to pick on in this series, but it also hasn't collected much in the way of reviews. For a fundamental change like this, I hope we can get more eyes on it. Thanks,
Alex