Re: [PATCH 05/10] PCI/P2PDMA: Export pci_p2pdma_map_type() function
From: Leon Romanovsky <leon@kernel.org>
Date: 2025-07-28 16:41:42
Also in:
dri-devel, kvm, linux-iommu, linux-media, linux-mm, linux-pci, lkml
On Mon, Jul 28, 2025 at 10:12:31AM -0600, Logan Gunthorpe wrote:
On 2025-07-27 13:05, Jason Gunthorpe wrote:quoted
On Fri, Jul 25, 2025 at 10:30:46AM -0600, Logan Gunthorpe wrote:quoted
On 2025-07-24 02:13, Leon Romanovsky wrote:quoted
On Thu, Jul 24, 2025 at 10:03:13AM +0200, Christoph Hellwig wrote:quoted
On Wed, Jul 23, 2025 at 04:00:06PM +0300, Leon Romanovsky wrote:quoted
From: Leon Romanovsky <leonro@nvidia.com> Export the pci_p2pdma_map_type() function to allow external modules and subsystems to determine the appropriate mapping type for P2PDMA transfers between a provider and target device.External modules have no business doing this.VFIO PCI code is built as module. There is no way to access PCI p2p code without exporting functions in it.The solution that would make more sense to me would be for either dma_iova_try_alloc() or another helper in dma-iommu.c to handle the P2PDMA case.This has nothing to do with dma-iommu.c, the decisions here still need to be made even if dma-iommu.c is not compiled in.Doesn't it though? Every single call in patch 10 to the newly exported PCI functions calls into the the dma-iommu functions. If there were non-iommu paths then I would expect the code would use the regular DMA api directly which would then call in to dma-iommu.
If p2p type is PCI_P2PDMA_MAP_BUS_ADDR, there will no dma-iommu and DMA
at all.
+static int vfio_pci_dma_buf_attach(struct dma_buf *dmabuf,
+ struct dma_buf_attachment *attachment)
+{
+ struct vfio_pci_dma_buf *priv = dmabuf->priv;
+
+ if (!attachment->peer2peer)
+ return -EOPNOTSUPP;
+
+ if (priv->revoked)
+ return -ENODEV;
+
+ switch (pci_p2pdma_map_type(priv->vdev->provider, attachment->dev)) {
+ case PCI_P2PDMA_MAP_THRU_HOST_BRIDGE:
+ break;
+ case PCI_P2PDMA_MAP_BUS_ADDR:
+ /*
+ * There is no need in IOVA at all for this flow.
+ * We rely on attachment->priv == NULL as a marker
+ * for this mode.
+ */
+ return 0;
+ default:
+ return -EINVAL;
+ }
+
+ attachment->priv = kzalloc(sizeof(struct dma_iova_state), GFP_KERNEL);
+ if (!attachment->priv)
+ return -ENOMEM;
+
+ dma_iova_try_alloc(attachment->dev, attachment->priv, 0, priv->phys_vec.len);
+ return 0;
+}