On Thu, Mar 05, 2026 at 01:36:40PM +0100, Jiri Pirko wrote:

From: Jiri Pirko jiri@nvidia.com

Current CC designs don't place a vIOMMU in front of untrusted devices. Instead, the DMA API forces all untrusted device DMA through swiotlb bounce buffers (is_swiotlb_force_bounce()) which copies data into decrypted memory on behalf of the device.

When a caller has already arranged for the memory to be decrypted via set_memory_decrypted(), the DMA API needs to know so it can map directly using the unencrypted physical address rather than bounce buffering. Following the pattern of DMA_ATTR_MMIO, add DMA_ATTR_CC_DECRYPTED for this purpose. Like the MMIO case, only the caller knows what kind of memory it has and must inform the DMA API for it to work correctly.

Signed-off-by: Jiri Pirko jiri@nvidia.com

v1->v2:

• rebased on top of recent dma-mapping-fixes

---

include/linux/dma-mapping.h | 6 ++++++ include/trace/events/dma.h | 3 ++- kernel/dma/direct.h | 14 +++++++++++--- 3 files changed, 19 insertions(+), 4 deletions(-)

diff --git a/include/linux/dma-mapping.h b/include/linux/dma-mapping.h index 29973baa0581..ae3d85e494ec 100644 --- a/include/linux/dma-mapping.h +++ b/include/linux/dma-mapping.h @@ -85,6 +85,12 @@

• a cacheline must have this attribute for this to be considered safe.

*/ #define DMA_ATTR_CPU_CACHE_CLEAN (1UL << 11) +/*

• • DMA_ATTR_CC_DECRYPTED: Indicates memory that has been explicitly decrypted
• • (shared) for confidential computing guests. The caller must have
• • called set_memory_decrypted(). A struct page is required.
• */

+#define DMA_ATTR_CC_DECRYPTED (1UL << 12)

While adding the new attribute is fine, I would expect additional checks in dma_map_phys() to ensure the attribute cannot be misused. For example, WARN_ON(attrs & (DMA_ATTR_CC_DECRYPTED | DMA_ATTR_MMIO)), along with a check that we are taking the direct path only.

Thanks