Re: [PATCH v5 2/9] PCI/P2PDMA: Add CONFIG_PCI_P2PDMA_CORE

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