> From: Matt Evans <[email protected]> > Sent: Wednesday, June 10, 2026 11:43 PM > > Convert the VFIO device fd fops->mmap to create a DMABUF representing > the BAR mapping, and make the VMA fault handler look up PFNs from the > corresponding DMABUF. This supports future code mmap()ing BAR > DMABUFs, and iommufd work to support Type1 P2P. > > First, vfio_pci_core_mmap() uses the new > vfio_pci_core_mmap_prep_dmabuf() helper to export a DMABUF > representing a single BAR range. Then, the vfio_pci_mmap_huge_fault() > callback is updated to understand revoked buffers, and uses the new > vfio_pci_dma_buf_find_pfn() helper to determine the PFN for a given > fault address. > > Now that the VFIO DMABUFs can be mmap()ed, vfio_pci_dma_buf_move() > zaps PTEs (used on the revocation and cleanup paths). > > CONFIG_VFIO_PCI_CORE now unconditionally depends on > CONFIG_DMA_SHARED_BUFFER and CONFIG_PCI_P2PDMA_CORE. The > CONFIG_VFIO_PCI_DMABUF feature conditionally includes support for > VFIO_DEVICE_FEATURE_DMA_BUF, depending on the availability of > CONFIG_PCI_P2PDMA. > > Signed-off-by: Matt Evans <[email protected]>
Reviewed-by: Kevin Tian <[email protected]> with a nit: > - vma->vm_private_data = vdev; > + /* > + * Create a DMABUF with a single range corresponding to this > + * mapping, and wire it into vma->vm_private_data. The VMA's > + * vm_file becomes that of the DMABUF, and the DMABUF takes > + * ownership of the VFIO device file (put upon DMABUF > + * release). This maintains the behaviour of a live VMA > + * mapping holding the VFIO device file open. > + */ > + ret = vfio_pci_core_mmap_prep_dmabuf(vdev, vma, > + pci_resource_start(pdev, index), > + req_len, index); the comment is redundant as it's about internal logic of the callee and is well covered by the comment there.
