From: Xu Yilun <yilun.xu@linux.intel.com>
To: kvm@vger.kernel.org, sumit.semwal@linaro.org,
christian.koenig@amd.com, pbonzini@redhat.com, seanjc@google.com,
alex.williamson@redhat.com, jgg@nvidia.com,
dan.j.williams@intel.com, aik@amd.com,
linux-coco@lists.linux.dev
Cc: dri-devel@lists.freedesktop.org, linux-media@vger.kernel.org,
linaro-mm-sig@lists.linaro.org, vivek.kasireddy@intel.com,
yilun.xu@intel.com, yilun.xu@linux.intel.com,
linux-kernel@vger.kernel.org, lukas@wunner.de,
yan.y.zhao@intel.com, daniel.vetter@ffwll.ch, leon@kernel.org,
baolu.lu@linux.intel.com, zhenzhong.duan@intel.com,
tao1.su@intel.com, linux-pci@vger.kernel.org, zhiw@nvidia.com,
simona.vetter@ffwll.ch, shameerali.kolothum.thodi@huawei.com,
aneesh.kumar@kernel.org, iommu@lists.linux.dev,
kevin.tian@intel.com
Subject: [RFC PATCH 01/30] HACK: dma-buf: Introduce dma_buf_get_pfn_unlocked() kAPI
Date: Thu, 29 May 2025 13:34:44 +0800 [thread overview]
Message-ID: <20250529053513.1592088-2-yilun.xu@linux.intel.com> (raw)
In-Reply-To: <20250529053513.1592088-1-yilun.xu@linux.intel.com>
This is just to illustrate the idea that dma-buf provides a new buffer
sharing mode - importer mapping. Exporter provides the target memory
resource description, importer decides what's the best way to map the
memory based on the information of target memory and importing device.
The get_pfn() kAPI is an initial attempt of this idea, obviously it is
not a full description for all kinds of memory types. But it enables
the FD based MMIO mapping in KVM to support private device assignement,
There are other concerns discussed [1] for this implementation, need
further investigation to work out a improved solution.
For now, no change to the previous version. [1]
[1]: https://lore.kernel.org/all/20250107142719.179636-2-yilun.xu@linux.intel.com/
Signed-off-by: Xu Yilun <yilun.xu@linux.intel.com>
---
drivers/dma-buf/dma-buf.c | 87 +++++++++++++++++++++++++++++++--------
include/linux/dma-buf.h | 13 ++++++
2 files changed, 83 insertions(+), 17 deletions(-)
diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c
index 5baa83b85515..58752f0bee36 100644
--- a/drivers/dma-buf/dma-buf.c
+++ b/drivers/dma-buf/dma-buf.c
@@ -630,10 +630,10 @@ struct dma_buf *dma_buf_export(const struct dma_buf_export_info *exp_info)
size_t alloc_size = sizeof(struct dma_buf);
int ret;
- if (WARN_ON(!exp_info->priv || !exp_info->ops
- || !exp_info->ops->map_dma_buf
- || !exp_info->ops->unmap_dma_buf
- || !exp_info->ops->release))
+ if (WARN_ON(!exp_info->priv || !exp_info->ops ||
+ (!!exp_info->ops->map_dma_buf != !!exp_info->ops->unmap_dma_buf) ||
+ (!exp_info->ops->map_dma_buf && !exp_info->ops->get_pfn) ||
+ !exp_info->ops->release))
return ERR_PTR(-EINVAL);
if (WARN_ON(exp_info->ops->cache_sgt_mapping &&
@@ -909,7 +909,7 @@ dma_buf_dynamic_attach(struct dma_buf *dmabuf, struct device *dev,
struct dma_buf_attachment *attach;
int ret;
- if (WARN_ON(!dmabuf || !dev))
+ if (WARN_ON(!dmabuf))
return ERR_PTR(-EINVAL);
if (WARN_ON(importer_ops && !importer_ops->move_notify))
@@ -941,7 +941,7 @@ dma_buf_dynamic_attach(struct dma_buf *dmabuf, struct device *dev,
*/
if (dma_buf_attachment_is_dynamic(attach) !=
dma_buf_is_dynamic(dmabuf)) {
- struct sg_table *sgt;
+ struct sg_table *sgt = NULL;
dma_resv_lock(attach->dmabuf->resv, NULL);
if (dma_buf_is_dynamic(attach->dmabuf)) {
@@ -950,13 +950,16 @@ dma_buf_dynamic_attach(struct dma_buf *dmabuf, struct device *dev,
goto err_unlock;
}
- sgt = __map_dma_buf(attach, DMA_BIDIRECTIONAL);
- if (!sgt)
- sgt = ERR_PTR(-ENOMEM);
- if (IS_ERR(sgt)) {
- ret = PTR_ERR(sgt);
- goto err_unpin;
+ if (dev && dmabuf->ops->map_dma_buf) {
+ sgt = __map_dma_buf(attach, DMA_BIDIRECTIONAL);
+ if (!sgt)
+ sgt = ERR_PTR(-ENOMEM);
+ if (IS_ERR(sgt)) {
+ ret = PTR_ERR(sgt);
+ goto err_unpin;
+ }
}
+
dma_resv_unlock(attach->dmabuf->resv);
attach->sgt = sgt;
attach->dir = DMA_BIDIRECTIONAL;
@@ -1119,7 +1122,8 @@ struct sg_table *dma_buf_map_attachment(struct dma_buf_attachment *attach,
might_sleep();
- if (WARN_ON(!attach || !attach->dmabuf))
+ if (WARN_ON(!attach || !attach->dmabuf || !attach->dev ||
+ !attach->dmabuf->ops->map_dma_buf))
return ERR_PTR(-EINVAL);
dma_resv_assert_held(attach->dmabuf->resv);
@@ -1195,7 +1199,8 @@ dma_buf_map_attachment_unlocked(struct dma_buf_attachment *attach,
might_sleep();
- if (WARN_ON(!attach || !attach->dmabuf))
+ if (WARN_ON(!attach || !attach->dmabuf || !attach->dev ||
+ !attach->dmabuf->ops->map_dma_buf))
return ERR_PTR(-EINVAL);
dma_resv_lock(attach->dmabuf->resv, NULL);
@@ -1222,7 +1227,8 @@ void dma_buf_unmap_attachment(struct dma_buf_attachment *attach,
{
might_sleep();
- if (WARN_ON(!attach || !attach->dmabuf || !sg_table))
+ if (WARN_ON(!attach || !attach->dmabuf || !attach->dev ||
+ !attach->dmabuf->ops->unmap_dma_buf || !sg_table))
return;
dma_resv_assert_held(attach->dmabuf->resv);
@@ -1254,7 +1260,8 @@ void dma_buf_unmap_attachment_unlocked(struct dma_buf_attachment *attach,
{
might_sleep();
- if (WARN_ON(!attach || !attach->dmabuf || !sg_table))
+ if (WARN_ON(!attach || !attach->dmabuf || !attach->dev ||
+ !attach->dmabuf->ops->unmap_dma_buf || !sg_table))
return;
dma_resv_lock(attach->dmabuf->resv, NULL);
@@ -1263,6 +1270,52 @@ void dma_buf_unmap_attachment_unlocked(struct dma_buf_attachment *attach,
}
EXPORT_SYMBOL_NS_GPL(dma_buf_unmap_attachment_unlocked, "DMA_BUF");
+/**
+ * dma_buf_get_pfn_unlocked -
+ * @attach: [in] attachment to get pfn from
+ * @pgoff: [in] page offset of the buffer against the start of dma_buf
+ * @pfn: [out] returns the pfn of the buffer
+ * @max_order [out] returns the max mapping order of the buffer
+ */
+int dma_buf_get_pfn_unlocked(struct dma_buf_attachment *attach,
+ pgoff_t pgoff, u64 *pfn, int *max_order)
+{
+ struct dma_buf *dmabuf = attach->dmabuf;
+ int ret;
+
+ if (WARN_ON(!attach || !attach->dmabuf ||
+ !attach->dmabuf->ops->get_pfn))
+ return -EINVAL;
+
+ /*
+ * Open:
+ *
+ * When dma_buf is dynamic but dma_buf move is disabled, the buffer
+ * should be pinned before use, See dma_buf_map_attachment() for
+ * reference.
+ *
+ * But for now no pin is intended inside dma_buf_get_pfn(), otherwise
+ * need another API to unpin the dma_buf. So just fail out this case.
+ */
+ if (dma_buf_is_dynamic(attach->dmabuf) &&
+ !IS_ENABLED(CONFIG_DMABUF_MOVE_NOTIFY))
+ return -ENOENT;
+
+ dma_resv_lock(attach->dmabuf->resv, NULL);
+ ret = dmabuf->ops->get_pfn(attach, pgoff, pfn, max_order);
+ /*
+ * Open:
+ *
+ * Is dma_resv_wait_timeout() needed? I assume no. The DMA buffer
+ * content synchronization could be done when the buffer is to be
+ * mapped by importer.
+ */
+ dma_resv_unlock(attach->dmabuf->resv);
+
+ return ret;
+}
+EXPORT_SYMBOL_NS_GPL(dma_buf_get_pfn_unlocked, "DMA_BUF");
+
/**
* dma_buf_move_notify - notify attachments that DMA-buf is moving
*
@@ -1662,7 +1715,7 @@ static int dma_buf_debug_show(struct seq_file *s, void *unused)
attach_count = 0;
list_for_each_entry(attach_obj, &buf_obj->attachments, node) {
- seq_printf(s, "\t%s\n", dev_name(attach_obj->dev));
+ seq_printf(s, "\t%s\n", attach_obj->dev ? dev_name(attach_obj->dev) : NULL);
attach_count++;
}
dma_resv_unlock(buf_obj->resv);
diff --git a/include/linux/dma-buf.h b/include/linux/dma-buf.h
index 36216d28d8bd..b16183edfb3a 100644
--- a/include/linux/dma-buf.h
+++ b/include/linux/dma-buf.h
@@ -194,6 +194,17 @@ struct dma_buf_ops {
* if the call would block.
*/
+ /**
+ * @get_pfn:
+ *
+ * This is called by dma_buf_get_pfn(). It is used to get the pfn
+ * of the buffer positioned by the page offset against the start of
+ * the dma_buf. It can only be called if @attach has been called
+ * successfully.
+ */
+ int (*get_pfn)(struct dma_buf_attachment *attach, pgoff_t pgoff,
+ u64 *pfn, int *max_order);
+
/**
* @release:
*
@@ -629,6 +640,8 @@ dma_buf_map_attachment_unlocked(struct dma_buf_attachment *attach,
void dma_buf_unmap_attachment_unlocked(struct dma_buf_attachment *attach,
struct sg_table *sg_table,
enum dma_data_direction direction);
+int dma_buf_get_pfn_unlocked(struct dma_buf_attachment *attach,
+ pgoff_t pgoff, u64 *pfn, int *max_order);
int dma_buf_mmap(struct dma_buf *, struct vm_area_struct *,
unsigned long);
--
2.25.1
next prev parent reply other threads:[~2025-05-29 5:41 UTC|newest]
Thread overview: 68+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-05-29 5:34 [RFC PATCH 00/30] Host side (KVM/VFIO/IOMMUFD) support for TDISP using TSM Xu Yilun
2025-05-29 5:34 ` Xu Yilun [this message]
2025-05-29 5:34 ` [RFC PATCH 02/30] vfio: Export vfio device get and put registration helpers Xu Yilun
2025-05-29 5:34 ` [RFC PATCH 03/30] vfio/pci: Share the core device pointer while invoking feature functions Xu Yilun
2025-05-29 5:34 ` [RFC PATCH 04/30] vfio/pci: Allow MMIO regions to be exported through dma-buf Xu Yilun
2025-05-29 5:34 ` [RFC PATCH 05/30] fixup! vfio/pci: fix dma-buf revoke typo on reset Xu Yilun
2025-05-29 5:34 ` [RFC PATCH 06/30] HACK: vfio/pci: Support get_pfn() callback for dma-buf Xu Yilun
2025-05-29 5:34 ` [RFC PATCH 07/30] KVM: Support vfio_dmabuf backed MMIO region Xu Yilun
2025-05-29 5:34 ` [RFC PATCH 08/30] KVM: x86/mmu: Handle page fault for vfio_dmabuf backed MMIO Xu Yilun
2025-05-29 5:34 ` [RFC PATCH 09/30] KVM: x86/mmu: Handle page fault for private MMIO Xu Yilun
2025-05-29 5:34 ` [RFC PATCH 10/30] vfio/pci: Export vfio dma-buf specific info for importers Xu Yilun
2025-06-02 13:30 ` Jason Gunthorpe
2025-06-03 5:01 ` Xu Yilun
2025-05-29 5:34 ` [RFC PATCH 11/30] KVM: vfio_dmabuf: Fetch VFIO specific dma-buf data for sanity check Xu Yilun
2025-05-29 5:34 ` [RFC PATCH 12/30] iommufd/device: Associate a kvm pointer to iommufd_device Xu Yilun
2025-05-29 5:34 ` [RFC PATCH 13/30] fixup! iommufd/selftest: Sync iommufd_device_bind() change to selftest Xu Yilun
2025-05-29 5:34 ` [RFC PATCH 14/30] iommu/arm-smmu-v3-iommufd: Pass in kvm pointer to viommu_alloc Xu Yilun
2025-05-29 5:34 ` [RFC PATCH 15/30] fixup: iommu/selftest: Sync .viommu_alloc() change to selftest Xu Yilun
2025-05-29 5:34 ` [RFC PATCH 16/30] iommufd/viommu: track the kvm pointer & its refcount in viommu core Xu Yilun
2025-05-29 5:35 ` [RFC PATCH 17/30] iommufd/device: Add TSM Bind/Unbind for TIO support Xu Yilun
2025-06-02 12:43 ` Aneesh Kumar K.V
2025-06-03 6:20 ` Xu Yilun
2025-06-03 12:21 ` Jason Gunthorpe
2025-06-04 8:40 ` Aneesh Kumar K.V
2025-06-04 13:24 ` Jason Gunthorpe
2025-06-06 7:59 ` Aneesh Kumar K.V
2025-05-29 5:35 ` [RFC PATCH 18/30] iommufd/viommu: Add trusted IOMMU configuration handlers for vdev Xu Yilun
2025-05-29 5:35 ` [RFC PATCH 19/30] vfio/pci: Add TSM TDI bind/unbind IOCTLs for TEE-IO support Xu Yilun
2025-06-01 10:45 ` Aneesh Kumar K.V
2025-06-02 14:43 ` Xu Yilun
2025-06-04 13:37 ` Aneesh Kumar K.V
2025-06-05 9:41 ` Xu Yilun
2025-06-05 15:09 ` Jason Gunthorpe
2025-06-06 3:25 ` Xu Yilun
2025-06-05 16:09 ` Aneesh Kumar K.V
2025-06-16 8:16 ` Aneesh Kumar K.V
2025-06-18 4:54 ` Xu Yilun
2025-06-05 12:03 ` Aneesh Kumar K.V
2025-06-05 15:10 ` Jason Gunthorpe
2025-06-05 16:17 ` Aneesh Kumar K.V
2025-06-05 16:33 ` Jason Gunthorpe
2025-06-06 4:26 ` Xu Yilun
2025-06-06 9:32 ` Aneesh Kumar K.V
2025-06-06 12:09 ` Jason Gunthorpe
2025-05-29 5:35 ` [RFC PATCH 20/30] vfio/pci: Do TSM Unbind before zapping bars Xu Yilun
2025-06-02 5:20 ` Aneesh Kumar K.V
2025-06-02 13:56 ` Xu Yilun
2025-06-02 14:00 ` Aneesh Kumar K.V
2025-06-03 4:50 ` Xu Yilun
2025-05-29 5:35 ` [RFC PATCH 21/30] iommufd/vdevice: Add TSM Guest request uAPI Xu Yilun
2025-05-29 5:35 ` [RFC PATCH 22/30] fixup! PCI/TSM: Change the guest request type definition Xu Yilun
2025-05-29 5:35 ` [RFC PATCH 23/30] coco/tdx_tsm: Introduce a "tdx" subsystem and "tsm" device Xu Yilun
2025-05-29 5:35 ` [RFC PATCH 24/30] coco/tdx_tsm: TEE Security Manager driver for TDX Xu Yilun
2025-05-29 5:35 ` [RFC PATCH 25/30] coco/tdx_tsm: Add connect()/disconnect() handlers prototype Xu Yilun
2025-05-29 5:35 ` [RFC PATCH 26/30] coco/tdx_tsm: Add bind()/unbind()/guest_req() " Xu Yilun
2025-05-29 5:35 ` [RFC PATCH 27/30] PCI/TSM: Add PCI driver callbacks to handle TSM requirements Xu Yilun
2025-06-02 13:06 ` Aneesh Kumar K.V
2025-06-03 5:52 ` Xu Yilun
2025-05-29 5:35 ` [RFC PATCH 28/30] vfio/pci: Implement TSM handlers for MMIO Xu Yilun
2025-05-29 5:35 ` [RFC PATCH 29/30] iommufd/vdevice: Implement TSM handlers for trusted DMA Xu Yilun
2025-05-29 5:35 ` [RFC PATCH 30/30] coco/tdx_tsm: Manage TDX Module enforced operation sequences for Unbind Xu Yilun
2025-06-02 13:37 ` [RFC PATCH 00/30] Host side (KVM/VFIO/IOMMUFD) support for TDISP using TSM Jason Gunthorpe
2025-06-20 4:21 ` Xu Yilun
2025-06-11 1:55 ` Alexey Kardashevskiy
2025-06-21 1:07 ` Alexey Kardashevskiy
2025-06-25 10:45 ` Xu Yilun
2025-07-11 23:08 ` dan.j.williams
2025-07-15 11:09 ` Jonathan Cameron
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=20250529053513.1592088-2-yilun.xu@linux.intel.com \
--to=yilun.xu@linux.intel.com \
--cc=aik@amd.com \
--cc=alex.williamson@redhat.com \
--cc=aneesh.kumar@kernel.org \
--cc=baolu.lu@linux.intel.com \
--cc=christian.koenig@amd.com \
--cc=dan.j.williams@intel.com \
--cc=daniel.vetter@ffwll.ch \
--cc=dri-devel@lists.freedesktop.org \
--cc=iommu@lists.linux.dev \
--cc=jgg@nvidia.com \
--cc=kevin.tian@intel.com \
--cc=kvm@vger.kernel.org \
--cc=leon@kernel.org \
--cc=linaro-mm-sig@lists.linaro.org \
--cc=linux-coco@lists.linux.dev \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-media@vger.kernel.org \
--cc=linux-pci@vger.kernel.org \
--cc=lukas@wunner.de \
--cc=pbonzini@redhat.com \
--cc=seanjc@google.com \
--cc=shameerali.kolothum.thodi@huawei.com \
--cc=simona.vetter@ffwll.ch \
--cc=sumit.semwal@linaro.org \
--cc=tao1.su@intel.com \
--cc=vivek.kasireddy@intel.com \
--cc=yan.y.zhao@intel.com \
--cc=yilun.xu@intel.com \
--cc=zhenzhong.duan@intel.com \
--cc=zhiw@nvidia.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;
as well as URLs for NNTP newsgroup(s).