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
