Hi Kevin, On 12/06/2026 09:46, Tian, Kevin wrote: >> 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.
Thanks on both points! I see what you mean, removed. Matt
