On Tue, Aug 11, 2026 at 02:45:59PM +0100, Matt Evans wrote:
So we can just do this:
- VFIO exports DMABUF internally for mmap()
- It attempts to get a provider for the export, but if
CONFIG_PCI_P2PDMA=n then provider is NULL.
- The DMABUF works fine for CPU access through the VMA
- If someone were to fish out the DMABUF from the VMA/fds then it cannot
be imported unless the provider is valid (dma_buf_map_attachment() returns -EINVAL)
- Drop the P2PDMA changes entirely
IOW, when CONFIG_PCI_P2PDMA=n you obviously don't get to import DMABUFs into another driver for P2P, so the provider is unused ... and when P2PDMA is supported, the VFIO BAR VMA's DMABUF has a provider, so could be imported for P2P. The struct vfio_pci_dma_buf only needs to have a valid provider if the DMABUF could possibly be imported of course.
The behaviour of pcim_p2pdma_provider() is unchanged, as are any other consumers such as mlx5.
This is way simpler. I will drop these first two P2PDMA refactor patches from this series. Sorry for the churn and time spent on these; though a cleanup/refactor could have merit separately it sounds like there's discussion needed on exactly what that goal should be.
We are going to want to do this eventually because not being able to import a dmabuf means vfio won't work with iommufd - and there are still a bunch of architectures that will be impacted by that coupling.
I'm fine with you punting on this issue though
Jason