On Tue, 6 Oct 2026 20:36:36 +0100 Matt Evans <[email protected]> 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
