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.co... [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