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

Reviewed-by: Kevin Tian kevin.tian@intel.com

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.