[RFC PATCH 0/2] iommu, drm/rockchip: Map private-domain imports from DMA addresses

[RFC PATCH 0/2] iommu, drm/rockchip: Map private-domain imports from DMA addresses

[Karl Mehltretter]

Diederik reported failed video-buffer imports on RK3588 with
DMABUF_DEBUG. The proposed warn-only mode [1] confirmed CPU-side
attachment access in rockchip_gem_iommu_map() during Sway video resizing.

This RFC keeps Rockchip's private scanout domain. Patch 1 copies live
iommu-dma mappings into another domain. Patch 2 uses it for PRIME
imports. Unsupported inputs keep the old page-based path, which remains
unfixed under strict DMABUF_DEBUG.

Rob's MSM approach assumes direct DMA [2]. Rockchip's attachment instead
provides IOVAs from the VOP's default domain, which cannot be mapped
unchanged into the private domain. Each import retains both mappings
and adds one reverse lookup per 4 KiB.

Christian rejected reverse translation in the earlier MSM proposal [3].
Robin NAKed exporting iommu_get_dma_domain() [4]. Keeping the helper in
dma-iommu.c does not resolve the physical-address objection.

Sharing the first VOP's default DMA domain, as Exynos does, would avoid
the translation but also change native-buffer mapping.

Is retaining the private domain and reverse-translating the DMA mappings
an acceptable direction? If so, I'll address the remaining limitations
before posting a non-RFC version.

Base: mainline 602042bf29f6. The warn-only RFC is not a prerequisite.
No stable backport requested. Strict-by-default DMABUF_DEBUG took effect
in v7.3-rc4.

Testing (builds and QEMU only):

- W=1 object and stub builds passed on arm64, ARM32 with/without LPAE,
  x86-64 GCC/Clang, i386, s390, RISC-V and UML, including dynamic SWIOTLB.
- Rockchip strict/warn A/B reproduced the control failure and warning.
  Treatments checked every page and byte in 83 imports each. Primary
  buffers had 1/127/507 DMA segments under the default 64 KiB limit.
- SMMUv3 strict/lazy tests, missing-source, bounds and rollback tests
  passed. Real bounced attachments exercised alignment and pool
  rejection with no target mapping or DMA.
- Invalid forced-SWIOTLB Rockchip provider runs are excluded. Expected
  segment-limit and unsupported-fallback diagnostics remain.

The rig uses a custom Rockchip IOMMU model and the real GEM callback in a
test module, not VOP2, Sway or a real exporter. RK3588 hardware, two-VOP
and 32-bit ARM runtime testing are outstanding.

Hardware testing is welcome, particularly with Diederik's Sway resize
workload. Compare control and both patches on the same base/config,
first with strict DMABUF_DEBUG, then with the warn-only RFC on both.
Please report full dmesg, config, exporter and visible display problems.
Keep a known-good boot kernel. DMABUF_DEBUG=n testing is welcome too.

Developed and tested with LLM assistance.

[1] https://lore.kernel.org/r/20261005064133.7305-1-kmehltretter@gmail.com/
[2] https://lore.kernel.org/r/20261006131000.81501-1-robin.clark@oss.qualcomm.com/
[3] https://lore.kernel.org/r/bd4e5ece-1358-4e0b-bb04-ba9de62d26f6@amd.com/
[4] https://lore.kernel.org/r/47bf9a4c-2a47-4e93-bcdf-8d953c9a5ab8@arm.com/

Reports:
https://lore.kernel.org/r/DLR74W1U9YPC.375IK0HOYHDIG@cknow-tech.com/
https://lore.kernel.org/r/DLYLA3WQNN3X.3FB9MO8ZWBQ5@cknow-tech.com/

Karl Mehltretter (2):
  iommu: Add iommu_map_sgtable_dma()
  drm/rockchip: Map imported buffers from DMA addresses

 drivers/gpu/drm/rockchip/rockchip_drm_gem.c |  19 ++-
 drivers/iommu/dma-iommu.c                   | 131 ++++++++++++++++++++
 include/linux/iommu.h                       |  12 ++
 3 files changed, 157 insertions(+), 5 deletions(-)


base-commit: 602042bf29f6efde39cfb5fdd9289bf4854bc0c5
-- 
2.53.0

[RFC PATCH 1/2] iommu: Add iommu_map_sgtable_dma()

[Karl Mehltretter]

DMA-BUF attachments provide DMA addresses, not CPU-side pages.
iommu_map_sgtable() needs those pages, so private-domain importers such
as Rockchip cannot use it with strict DMABUF_DEBUG.

Add an iommu-dma helper to map a live attachment into another domain by
translating through the device's default DMA domain. Roll back target
mappings on error. This still recovers physical addresses internally.

Only non-bounced iommu-dma mappings are supported. Other DMA backends,
marked bus addresses and zero translations return -EOPNOTSUPP, as does
the IOMMU_DMA=n stub. A zero lookup cannot distinguish a hole from PA0.
Reject bounce slots because a second mapping cannot keep them in sync
with writes to the original buffer.

DMABUF_DEBUG currently drops DMA flags from its copy, so the bus-address
check depends on the input retaining that mark.

Assisted-by: LLM
Signed-off-by: Karl Mehltretter <kmehltretter@gmail.com>
---
 drivers/iommu/dma-iommu.c | 131 ++++++++++++++++++++++++++++++++++++++
 include/linux/iommu.h     |  12 ++++
 2 files changed, 143 insertions(+)

diff --git a/drivers/iommu/dma-iommu.c b/drivers/iommu/dma-iommu.c
index 58c624513cd4..b9a1f91ec5db 100644
--- a/drivers/iommu/dma-iommu.c
+++ b/drivers/iommu/dma-iommu.c
@@ -38,6 +38,137 @@
 #include "dma-iommu.h"
 #include "iommu-pages.h"
 
+/**
+ * iommu_map_sgtable_dma - map the DMA side of an sg_table into a domain
+ * @domain: domain to map into
+ * @iova: IOVA of the first byte
+ * @dev: device for which @sgt is mapped
+ * @sgt: live DMA-API mapping for @dev, backed by non-bounced RAM
+ * @prot: IOMMU protection flags
+ *
+ * Translate the DMA addresses through @dev's default iommu-dma domain and
+ * map the backing memory into @domain without reading the CPU side of @sgt.
+ * Direct DMA and other DMA backends are not supported. Entries marked as
+ * PCI P2P bus addresses and SWIOTLB bounce buffers are also not supported.
+ *
+ * The caller must keep the source mapping, DMA backend and default domain
+ * unchanged until the target mapping is removed. This function may sleep.
+ * DMA addresses and lengths must be aligned to the smaller of the source
+ * and target domains' minimum page sizes. @iova and the total length must
+ * be aligned to the target domain's minimum page size.
+ *
+ * A zero reverse translation is unsupported: iommu_iova_to_phys() cannot
+ * distinguish an absent mapping from a mapping to physical address zero.
+ *
+ * Return: the number of bytes mapped, -EOPNOTSUPP for unsupported source
+ * mappings or source alignment, or another negative errno on error. Any
+ * target mappings installed by this call are removed on error.
+ */
+ssize_t iommu_map_sgtable_dma(struct iommu_domain *domain, unsigned long iova,
+			      struct device *dev, struct sg_table *sgt,
+			      int prot)
+{
+	struct iommu_domain *dma_domain;
+	size_t len = 0, mapped = 0, total = 0;
+	struct scatterlist *sg;
+	size_t granule, target_granule;
+	phys_addr_t start = 0;
+	unsigned long last_iova;
+	unsigned int i;
+	int ret;
+
+	if (!domain->pgsize_bitmap)
+		return -EINVAL;
+
+	target_granule = 1UL << __ffs(domain->pgsize_bitmap);
+	if (!use_dma_iommu(dev))
+		return -EOPNOTSUPP;
+	dma_domain = iommu_get_dma_domain(dev);
+	if (!dma_domain || !dma_domain->pgsize_bitmap)
+		return -EOPNOTSUPP;
+	granule = min(target_granule,
+		      1UL << __ffs(dma_domain->pgsize_bitmap));
+
+	for_each_sgtable_dma_sg(sgt, sg, i) {
+		dma_addr_t last_dma;
+		size_t dma_len = sg_dma_len(sg);
+
+		if (sg_dma_is_bus_address(sg))
+			return -EOPNOTSUPP;
+		if (!dma_len || !IS_ALIGNED(sg_dma_address(sg), granule) ||
+		    !IS_ALIGNED(dma_len, granule))
+			return -EOPNOTSUPP;
+		if (check_add_overflow(sg_dma_address(sg), dma_len - 1,
+				       &last_dma) ||
+		    check_add_overflow(total, dma_len, &total))
+			return -EOVERFLOW;
+	}
+	if (!total)
+		return 0;
+	if (total > SSIZE_MAX || !IS_ALIGNED(iova, target_granule) ||
+	    !IS_ALIGNED(total, target_granule))
+		return -EINVAL;
+	if (check_add_overflow(iova, total - 1, &last_iova))
+		return -EOVERFLOW;
+
+	for_each_sgtable_dma_sg(sgt, sg, i) {
+		dma_addr_t dma_addr = sg_dma_address(sg);
+		size_t dma_len = sg_dma_len(sg);
+
+		while (dma_len) {
+			phys_addr_t next;
+			phys_addr_t phys;
+
+			phys = iommu_iova_to_phys(dma_domain, dma_addr);
+			if (!phys || swiotlb_find_pool(dev, phys)) {
+				ret = -EOPNOTSUPP;
+				goto out_err;
+			}
+
+			if (len && check_add_overflow(start, len, &next)) {
+				ret = -EOVERFLOW;
+				goto out_err;
+			}
+			if (len && phys != next) {
+				ret = iommu_map_nosync(domain, iova + mapped,
+						       start, len, prot,
+						       GFP_KERNEL);
+				if (ret)
+					goto out_err;
+				mapped += len;
+				len = 0;
+			}
+			if (!len)
+				start = phys;
+			if (check_add_overflow(len, granule, &len)) {
+				ret = -EOVERFLOW;
+				goto out_err;
+			}
+			dma_addr += granule;
+			dma_len -= granule;
+		}
+	}
+
+	if (len) {
+		ret = iommu_map_nosync(domain, iova + mapped, start, len, prot,
+				       GFP_KERNEL);
+		if (ret)
+			goto out_err;
+		mapped += len;
+	}
+
+	ret = iommu_sync_map(domain, iova, mapped);
+	if (ret)
+		goto out_err;
+
+	return mapped;
+
+out_err:
+	iommu_unmap(domain, iova, mapped);
+	return ret;
+}
+EXPORT_SYMBOL_GPL(iommu_map_sgtable_dma);
+
 struct iommu_dma_msi_page {
 	struct list_head	list;
 	dma_addr_t		iova;
diff --git a/include/linux/iommu.h b/include/linux/iommu.h
index ac43b8b93f14..95d90c7f953b 100644
--- a/include/linux/iommu.h
+++ b/include/linux/iommu.h
@@ -1604,8 +1604,20 @@ static inline void iommu_debugfs_setup(void) {}
 #endif
 
 #ifdef CONFIG_IOMMU_DMA
+ssize_t iommu_map_sgtable_dma(struct iommu_domain *domain, unsigned long iova,
+			      struct device *dev, struct sg_table *sgt,
+			      int prot);
 int iommu_get_msi_cookie(struct iommu_domain *domain, dma_addr_t base);
 #else /* CONFIG_IOMMU_DMA */
+static inline ssize_t iommu_map_sgtable_dma(struct iommu_domain *domain,
+					    unsigned long iova,
+					    struct device *dev,
+					    struct sg_table *sgt,
+					    int prot)
+{
+	return -EOPNOTSUPP;
+}
+
 static inline int iommu_get_msi_cookie(struct iommu_domain *domain, dma_addr_t base)
 {
 	return -ENODEV;
-- 
2.53.0

Re: [RFC PATCH 1/2] iommu: Add iommu_map_sgtable_dma()

[Jason Gunthorpe]

On Fri, Oct 09, 2026 at 02:21:13AM +0200, Karl Mehltretter wrote:
> DMA-BUF attachments provide DMA addresses, not CPU-side pages.
> iommu_map_sgtable() needs those pages, so private-domain importers such
> as Rockchip cannot use it with strict DMABUF_DEBUG.
> 
> Add an iommu-dma helper to map a live attachment into another domain by
> translating through the device's default DMA domain. Roll back target
> mappings on error. This still recovers physical addresses
> internally.

Absolutely not. You cannot recover the phys_addr's from a DMABUF
expoter by using iommu_iova_to_phys(). Christian is adamant that
drivers must not use physical addresses, and I will not agree to any
hacks like this to try to end-run around his prohibition by abusing
iommu subsystem.

NAKed-by: Jason Gunthorpe <jgg@nvidia.com>

If you want to keep the domain in the rockchip driver you have to fix
DMABUF to allow an importer to use an iommu domain safely.

It *must not* be done with a scatterlist interface, sorry, I know that
is alot of work but Alistair is going to take a serious stab at it.

Many users want this, not just rockchip. So help with the work to
allow iommufd to do this and you will get it for free.

Jason

[RFC PATCH 2/2] drm/rockchip: Map imported buffers from DMA addresses

[Karl Mehltretter]

rockchip_gem_prime_import_sg_table() uses iommu_map_sgtable(), which reads
CPU-side pages and lengths. DMABUF_DEBUG clears these fields, causing
the RK3588 import failures reported by Diederik de Haas.

The attachment's DMA addresses belong to the VOP's default domain,
while scanout uses a separate DRM domain. Use iommu_map_sgtable_dma()
to copy the live mapping into that domain.

Keep native allocations unchanged. Unsupported imports still use the
old page-based path and remain unfixed under strict DMABUF_DEBUG.
This RFC retains reverse translation rather than sharing the DMA domain.

Reported-by: Diederik de Haas <diederik@cknow-tech.com>
Link: https://lore.kernel.org/r/DLR74W1U9YPC.375IK0HOYHDIG@cknow-tech.com/
Link: https://lore.kernel.org/r/DLYLA3WQNN3X.3FB9MO8ZWBQ5@cknow-tech.com/
Assisted-by: LLM
Signed-off-by: Karl Mehltretter <kmehltretter@gmail.com>
---
 drivers/gpu/drm/rockchip/rockchip_drm_gem.c | 19 ++++++++++++++-----
 1 file changed, 14 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_gem.c b/drivers/gpu/drm/rockchip/rockchip_drm_gem.c
index 9a1dc9f12072..501c94cb921a 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_gem.c
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_gem.c
@@ -20,7 +20,8 @@
 #include "rockchip_drm_drv.h"
 #include "rockchip_drm_gem.h"
 
-static int rockchip_gem_iommu_map(struct rockchip_gem_object *rk_obj)
+static int rockchip_gem_iommu_map(struct rockchip_gem_object *rk_obj,
+				  struct device *dma_dev)
 {
 	struct drm_device *drm = rk_obj->base.dev;
 	struct rockchip_drm_private *private = drm->dev_private;
@@ -40,8 +41,16 @@ static int rockchip_gem_iommu_map(struct rockchip_gem_object *rk_obj)
 
 	rk_obj->dma_addr = rk_obj->mm.start;
 
-	ret = iommu_map_sgtable(private->domain, rk_obj->dma_addr, rk_obj->sgt,
-				prot);
+	if (dma_dev) {
+		ret = iommu_map_sgtable_dma(private->domain, rk_obj->dma_addr,
+					    dma_dev, rk_obj->sgt, prot);
+		if (ret == -EOPNOTSUPP)
+			ret = iommu_map_sgtable(private->domain, rk_obj->dma_addr,
+						rk_obj->sgt, prot);
+	} else {
+		ret = iommu_map_sgtable(private->domain, rk_obj->dma_addr,
+					rk_obj->sgt, prot);
+	}
 	if (ret < (ssize_t)rk_obj->base.size) {
 		DRM_ERROR("failed to map buffer: size=%zd request_size=%zd\n",
 			  ret, rk_obj->base.size);
@@ -131,7 +140,7 @@ static int rockchip_gem_alloc_iommu(struct rockchip_gem_object *rk_obj,
 	if (ret < 0)
 		return ret;
 
-	ret = rockchip_gem_iommu_map(rk_obj);
+	ret = rockchip_gem_iommu_map(rk_obj, NULL);
 	if (ret < 0)
 		goto err_free;
 
@@ -457,7 +466,7 @@ rockchip_gem_iommu_map_sg(struct drm_device *drm,
 			  struct rockchip_gem_object *rk_obj)
 {
 	rk_obj->sgt = sg;
-	return rockchip_gem_iommu_map(rk_obj);
+	return rockchip_gem_iommu_map(rk_obj, attach->dev);
 }
 
 static int
-- 
2.53.0

Re: [RFC PATCH 0/2] iommu, drm/rockchip: Map private-domain imports from DMA addresses

[Robin Murphy]

On 09/10/2026 1:21 am, Karl Mehltretter wrote:
> Diederik reported failed video-buffer imports on RK3588 with
> DMABUF_DEBUG. The proposed warn-only mode [1] confirmed CPU-side
> attachment access in rockchip_gem_iommu_map() during Sway video resizing.
> 
> This RFC keeps Rockchip's private scanout domain. Patch 1 copies live
> iommu-dma mappings into another domain. Patch 2 uses it for PRIME
> imports. Unsupported inputs keep the old page-based path, which remains
> unfixed under strict DMABUF_DEBUG.
> 
> Rob's MSM approach assumes direct DMA [2]. Rockchip's attachment instead
> provides IOVAs from the VOP's default domain, which cannot be mapped
> unchanged into the private domain. Each import retains both mappings
> and adds one reverse lookup per 4 KiB.
> 
> Christian rejected reverse translation in the earlier MSM proposal [3].
> Robin NAKed exporting iommu_get_dma_domain() [4]. Keeping the helper in
> dma-iommu.c does not resolve the physical-address objection.

And if I'd had the context of the whole series, I would have said what I 
can see now, that the entire premise is fundamentally wrong, 
irrespective of abusing the internal helper or not.

> Sharing the first VOP's default DMA domain, as Exynos does, would avoid
> the translation but also change native-buffer mapping.
> 
> Is retaining the private domain and reverse-translating the DMA mappings
> an acceptable direction? If so, I'll address the remaining limitations
> before posting a non-RFC version.

No. If a driver has attached the device to its own unmanaged IOMMU 
domain then it is using that domain, not the default domain, and thus 
has even less reason to go poking at the default domain than usual 
(where the "usual" is tenuous enough in itself). In this situation DMA 
mapping only needs to take care of non-coherent cache maintenance, and 
32-bit ARM is actually the better example here.

The fact that iommu-dma does a load of unnecessary work and returns a 
bogus DMA address just to still get the cache maintenance as a 
side-effect is a hideous inefficiency (which folks have complained about 
before...) and absolutely should not be relied upon. It needs to go 
away. There were reasons why in the original iommu_dma_ops design it was 
rather impractical to do better (in fact iommu_get_dma_domain() itself 
is largely just a hack around some of those limitations), but since 
b67483b3c44e ("iommu/dma: Centralise iommu_setup_dma_ops()") and 
particularly b5c58b2fdc42 ("dma-mapping: direct calls for dma-iommu"), 
it now really could and should be cleaned up - it just needs something 
slightly different from the standard dma-direct behaviour, as for this 
case we need to ignore the DMA mask and any bouncing conditions.

Thanks,
Robin.
> Base: mainline 602042bf29f6. The warn-only RFC is not a prerequisite.
> No stable backport requested. Strict-by-default DMABUF_DEBUG took effect
> in v7.3-rc4.
> 
> Testing (builds and QEMU only):
> 
> - W=1 object and stub builds passed on arm64, ARM32 with/without LPAE,
>    x86-64 GCC/Clang, i386, s390, RISC-V and UML, including dynamic SWIOTLB.
> - Rockchip strict/warn A/B reproduced the control failure and warning.
>    Treatments checked every page and byte in 83 imports each. Primary
>    buffers had 1/127/507 DMA segments under the default 64 KiB limit.
> - SMMUv3 strict/lazy tests, missing-source, bounds and rollback tests
>    passed. Real bounced attachments exercised alignment and pool
>    rejection with no target mapping or DMA.
> - Invalid forced-SWIOTLB Rockchip provider runs are excluded. Expected
>    segment-limit and unsupported-fallback diagnostics remain.
> 
> The rig uses a custom Rockchip IOMMU model and the real GEM callback in a
> test module, not VOP2, Sway or a real exporter. RK3588 hardware, two-VOP
> and 32-bit ARM runtime testing are outstanding.
> 
> Hardware testing is welcome, particularly with Diederik's Sway resize
> workload. Compare control and both patches on the same base/config,
> first with strict DMABUF_DEBUG, then with the warn-only RFC on both.
> Please report full dmesg, config, exporter and visible display problems.
> Keep a known-good boot kernel. DMABUF_DEBUG=n testing is welcome too.
> 
> Developed and tested with LLM assistance.
> 
> [1] https://lore.kernel.org/r/20261005064133.7305-1-kmehltretter@gmail.com/
> [2] https://lore.kernel.org/r/20261006131000.81501-1-robin.clark@oss.qualcomm.com/
> [3] https://lore.kernel.org/r/bd4e5ece-1358-4e0b-bb04-ba9de62d26f6@amd.com/
> [4] https://lore.kernel.org/r/47bf9a4c-2a47-4e93-bcdf-8d953c9a5ab8@arm.com/
> 
> Reports:
> https://lore.kernel.org/r/DLR74W1U9YPC.375IK0HOYHDIG@cknow-tech.com/
> https://lore.kernel.org/r/DLYLA3WQNN3X.3FB9MO8ZWBQ5@cknow-tech.com/
> 
> Karl Mehltretter (2):
>    iommu: Add iommu_map_sgtable_dma()
>    drm/rockchip: Map imported buffers from DMA addresses
> 
>   drivers/gpu/drm/rockchip/rockchip_drm_gem.c |  19 ++-
>   drivers/iommu/dma-iommu.c                   | 131 ++++++++++++++++++++
>   include/linux/iommu.h                       |  12 ++
>   3 files changed, 157 insertions(+), 5 deletions(-)
> 
> 
> base-commit: 602042bf29f6efde39cfb5fdd9289bf4854bc0c5