Linux Kernel Selftest development
 help / color / mirror / Atom feed
From: Jason Gunthorpe <jgg@nvidia.com>
To: "Alex Williamson" <alex@shazbot.org>,
	"Christian König" <christian.koenig@amd.com>,
	dri-devel@lists.freedesktop.org, iommu@lists.linux.dev,
	"Joerg Roedel" <joro@8bytes.org>,
	"Kevin Tian" <kevin.tian@intel.com>,
	kvm@vger.kernel.org, linaro-mm-sig@lists.linaro.org,
	linux-kselftest@vger.kernel.org, linux-media@vger.kernel.org,
	"Robin Murphy" <robin.murphy@arm.com>,
	"Shuah Khan" <shuah@kernel.org>,
	"Sumit Semwal" <sumit.semwal@linaro.org>,
	"Will Deacon" <will@kernel.org>
Cc: Krishnakant Jaju <kjaju@nvidia.com>,
	Leon Romanovsky <leon@kernel.org>, Matt Ochs <mochs@nvidia.com>,
	Nicolin Chen <nicolinc@nvidia.com>,
	patches@lists.linux.dev, Simona Vetter <simona.vetter@ffwll.ch>,
	Vivek Kasireddy <vivek.kasireddy@intel.com>,
	Xu Yilun <yilun.xu@linux.intel.com>
Subject: [PATCH 1/9] vfio/pci: Add vfio_pci_dma_buf_iommufd_map()
Date: Fri,  7 Nov 2025 12:49:33 -0400	[thread overview]
Message-ID: <1-v1-af84a3ab44f5+f68-iommufd_buf_jgg@nvidia.com> (raw)
In-Reply-To: <0-v1-af84a3ab44f5+f68-iommufd_buf_jgg@nvidia.com>

This function is used to establish the "private interconnect" between the
VFIO DMABUF exporter and the iommufd DMABUF importer. This is intended to
be a temporary API until the core DMABUF interface is improved to natively
support a private interconnect and revocable negotiation.

This function should only be called by iommufd when trying to map a
DMABUF. For now iommufd will only support VFIO DMABUFs.

The following improvements are needed in the DMABUF API to generically
support more exporters with iommufd/kvm type importers that cannot use the
DMA API:

 1) Revoke semantics. VFIO needs to be able to prevent access to the MMIO
    during FLR, and so it will use dma_buf_move_notify() to prevent
    access. iommmufd does not support fault handling so it cannot
    implement the full move_notify. Instead if revoke is negotiated the
    exporter promises not to use move_notify() unless the importer can
    experiance failures. iommufd will unmap the dmabuf from the iommu page
    tables while it is revoked.

 2) Private interconnect negotiation. iommufd will only be able to map
    a "private interconnect" that provides a phys_addr_t and a
    struct p2pdma_provider * to describe the memory. It cannot use a DMA
    mapped scatterlist since it is directly calling iommu_map().

 3) NULL device during dma_buf_dynamic_attach(). Since iommufd doesn't use
    the DMA API it doesn't have a DMAable struct device to pass here.

Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
---
 drivers/vfio/pci/vfio_pci_dmabuf.c | 34 ++++++++++++++++++++++++++++++
 include/linux/vfio_pci_core.h      |  4 ++++
 2 files changed, 38 insertions(+)

diff --git a/drivers/vfio/pci/vfio_pci_dmabuf.c b/drivers/vfio/pci/vfio_pci_dmabuf.c
index cbf502b14e3c02..7cafd944ce5d38 100644
--- a/drivers/vfio/pci/vfio_pci_dmabuf.c
+++ b/drivers/vfio/pci/vfio_pci_dmabuf.c
@@ -81,6 +81,40 @@ static const struct dma_buf_ops vfio_pci_dmabuf_ops = {
 	.release = vfio_pci_dma_buf_release,
 };
 
+/*
+ * This is a temporary "private interconnect" between VFIO DMABUF and iommufd.
+ * It allows the two co-operating drivers to exchange the physical address of
+ * the BAR. This is to be replaced with a formal DMABUF system for negotiated
+ * interconnect types.
+ *
+ * If this function succeeds the following are true:
+ *  - There is one physical range and it is pointing to MMIO
+ *  - When move_notify is called it means revoke, not move, vfio_dma_buf_map
+ *    will fail if it is currently revoked
+ */
+int vfio_pci_dma_buf_iommufd_map(struct dma_buf_attachment *attachment,
+				 struct dma_buf_phys_vec *phys)
+{
+	struct vfio_pci_dma_buf *priv;
+
+	dma_resv_assert_held(attachment->dmabuf->resv);
+
+	if (attachment->dmabuf->ops != &vfio_pci_dmabuf_ops)
+		return -EOPNOTSUPP;
+
+	priv = attachment->dmabuf->priv;
+	if (priv->revoked)
+		return -ENODEV;
+
+	/* More than one range to iommufd will require proper DMABUF support */
+	if (priv->nr_ranges != 1)
+		return -EOPNOTSUPP;
+
+	*phys = priv->phys_vec[0];
+	return 0;
+}
+EXPORT_SYMBOL_FOR_MODULES(vfio_pci_dma_buf_iommufd_map, "iommufd");
+
 int vfio_pci_core_fill_phys_vec(struct dma_buf_phys_vec *phys_vec,
 				struct vfio_region_dma_range *dma_ranges,
 				size_t nr_ranges, phys_addr_t start,
diff --git a/include/linux/vfio_pci_core.h b/include/linux/vfio_pci_core.h
index c9466ba323fa9c..6a3074f2cf1cea 100644
--- a/include/linux/vfio_pci_core.h
+++ b/include/linux/vfio_pci_core.h
@@ -28,6 +28,7 @@ struct vfio_pci_core_device;
 struct vfio_pci_region;
 struct p2pdma_provider;
 struct dma_buf_phys_vec;
+struct dma_buf_attachment;
 
 struct vfio_pci_regops {
 	ssize_t (*rw)(struct vfio_pci_core_device *vdev, char __user *buf,
@@ -203,4 +204,7 @@ VFIO_IOREAD_DECLARATION(32)
 VFIO_IOREAD_DECLARATION(64)
 #endif
 
+int vfio_pci_dma_buf_iommufd_map(struct dma_buf_attachment *attachment,
+				 struct dma_buf_phys_vec *phys);
+
 #endif /* VFIO_PCI_CORE_H */
-- 
2.43.0


  reply	other threads:[~2025-11-07 16:49 UTC|newest]

Thread overview: 45+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-11-07 16:49 [PATCH 0/9] Initial DMABUF support for iommufd Jason Gunthorpe
2025-11-07 16:49 ` Jason Gunthorpe [this message]
2025-11-20  7:49   ` [PATCH 1/9] vfio/pci: Add vfio_pci_dma_buf_iommufd_map() Tian, Kevin
2025-11-20 17:34   ` Nicolin Chen
2025-11-07 16:49 ` [PATCH 2/9] iommufd: Add DMABUF to iopt_pages Jason Gunthorpe
2025-11-07 18:02   ` Nicolin Chen
2025-11-20  7:55   ` Tian, Kevin
2025-11-21 14:27     ` Jason Gunthorpe
2025-11-07 16:49 ` [PATCH 3/9] iommufd: Do not map/unmap revoked DMABUFs Jason Gunthorpe
2025-11-07 18:30   ` Nicolin Chen
2025-11-20  7:56   ` Tian, Kevin
2025-11-07 16:49 ` [PATCH 4/9] iommufd: Allow a DMABUF to be revoked Jason Gunthorpe
2025-11-13 23:26   ` Nicolin Chen
2025-11-20  7:58   ` Tian, Kevin
2025-11-07 16:49 ` [PATCH 5/9] iommufd: Allow MMIO pages in a batch Jason Gunthorpe
2025-11-13 23:28   ` Nicolin Chen
2025-11-20  7:59   ` Tian, Kevin
2025-11-20 14:59     ` Jason Gunthorpe
2025-11-07 16:49 ` [PATCH 6/9] iommufd: Have pfn_reader process DMABUF iopt_pages Jason Gunthorpe
2025-11-13 23:39   ` Nicolin Chen
2025-11-18 19:38     ` Jason Gunthorpe
2025-11-20  8:04   ` Tian, Kevin
2025-11-21  0:47     ` Jason Gunthorpe
2025-11-21 14:33       ` Jason Gunthorpe
2025-11-07 16:49 ` [PATCH 7/9] iommufd: Have iopt_map_file_pages convert the fd to a file Jason Gunthorpe
2025-11-13 23:43   ` Nicolin Chen
2025-11-20  8:05   ` Tian, Kevin
2025-11-07 16:49 ` [PATCH 8/9] iommufd: Accept a DMABUF through IOMMU_IOAS_MAP_FILE Jason Gunthorpe
2025-11-14  0:05   ` Nicolin Chen
2025-11-18 19:44     ` Jason Gunthorpe
2025-11-18 19:57       ` Nicolin Chen
2025-11-20  8:06   ` Tian, Kevin
2025-11-07 16:49 ` [PATCH 9/9] iommufd/selftest: Add some tests for the dmabuf flow Jason Gunthorpe
2025-11-07 19:43   ` Nicolin Chen
2025-11-18 19:25     ` Jason Gunthorpe
2025-11-20  8:06       ` Tian, Kevin
2025-11-07 17:52 ` [PATCH 0/9] Initial DMABUF support for iommufd Nicolin Chen
2025-11-13  6:33   ` Shuai Xue
2025-11-13  7:34     ` Nicolin Chen
2025-11-13 11:32       ` Shuai Xue
2025-11-13 17:44         ` Nicolin Chen
2025-11-13 18:37 ` Alex Williamson
2025-11-17 15:50   ` Jason Gunthorpe
2025-11-18  5:37     ` Kasireddy, Vivek
2025-11-18 14:59       ` Jason Gunthorpe

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1-v1-af84a3ab44f5+f68-iommufd_buf_jgg@nvidia.com \
    --to=jgg@nvidia.com \
    --cc=alex@shazbot.org \
    --cc=christian.koenig@amd.com \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=iommu@lists.linux.dev \
    --cc=joro@8bytes.org \
    --cc=kevin.tian@intel.com \
    --cc=kjaju@nvidia.com \
    --cc=kvm@vger.kernel.org \
    --cc=leon@kernel.org \
    --cc=linaro-mm-sig@lists.linaro.org \
    --cc=linux-kselftest@vger.kernel.org \
    --cc=linux-media@vger.kernel.org \
    --cc=mochs@nvidia.com \
    --cc=nicolinc@nvidia.com \
    --cc=patches@lists.linux.dev \
    --cc=robin.murphy@arm.com \
    --cc=shuah@kernel.org \
    --cc=simona.vetter@ffwll.ch \
    --cc=sumit.semwal@linaro.org \
    --cc=vivek.kasireddy@intel.com \
    --cc=will@kernel.org \
    --cc=yilun.xu@linux.intel.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox