dma-mapping: Use DMA_ATTR_CC_SHARED through direct, pool and swiotlb paths

PATCH Superseded Aneesh Kumar K.V (Arm) 4 participants 22 messages Apr 20 – Jun 3

Subsystems (3)

IOMMU DMA mapping helpers IOMMU DMA-API layer

lore

Share & tools

lore

Aneesh Kumar K.V (Arm)

author

2026-04-20 06:14 UTC #0 lore raw

v2 cover dma-mapping: Use DMA_ATTR_CC_SHARED through direct, pool and swiotlb paths

This series propagates DMA_ATTR_CC_SHARED through the dma-direct, dma-pool, and swiotlb paths so that encrypted and decrypted DMA buffers are handled consistently.

Today, the direct DMA path mostly relies on force_dma_unencrypted() for shared/decrypted buffer handling. This series consolidates the force_dma_unencrypted() checks in the top-level functions and ensures that the remaining DMA interfaces use DMA attributes to make the correct decisions.

The series:
- moves swiotlb-backed allocations out of __dma_direct_alloc_pages(),
- propagates DMA_ATTR_CC_SHARED through the dma-direct alloc/free paths,
- teaches the atomic DMA pools to track encrypted versus decrypted state,
- tracks swiotlb pool encryption state and enforces strict pool selection,
- centralizes encrypted/decrypted pgprot handling in dma_pgprot() using DMA attributes,
- makes dma_direct_map_phys() choose the DMA address encoding from attrs, and
- uses the selected swiotlb pool state to derive the returned DMA address.

Changes from v1:
* rebased to latest kernel (change from DMA_ATTR_CC_DECRYPTED -> DMA_ATTR_CC_SHARED)
* Update alloc path such that DMA_ATTR_CC_SHARED s not a caller-visible attribute.

Aneesh Kumar K.V (Arm) (8):
dma-direct: swiotlb: handle swiotlb alloc/free outside
__dma_direct_alloc_pages
dma-direct: use DMA_ATTR_CC_SHARED in alloc/free paths
dma-pool: track decrypted atomic pools and select them via attrs
dma: swiotlb: track pool encryption state and honor DMA_ATTR_CC_SHARED
dma-mapping: make dma_pgprot() honor DMA_ATTR_CC_SHARED
dma-direct: make dma_direct_map_phys() honor DMA_ATTR_CC_SHARED
dma-direct: set decrypted flag for remapped DMA allocations
dma-direct: select DMA address encoding from DMA_ATTR_CC_SHARED

 drivers/iommu/dma-iommu.c   |   2 +-
 include/linux/dma-direct.h  |  10 ++
 include/linux/dma-map-ops.h |   2 +-
 include/linux/swiotlb.h     |   7 +-
 kernel/dma/direct.c         | 185 ++++++++++++++++++++++++++++--------
 kernel/dma/direct.h         |  25 ++---
 kernel/dma/mapping.c        |  16 +++-
 kernel/dma/pool.c           | 154 +++++++++++++++++++-----------
 kernel/dma/swiotlb.c        |  89 +++++++++++++----
 9 files changed, 355 insertions(+), 135 deletions(-)

base-commit: c1f49dea2b8f335813d3b348fd39117fb8efb428

Signature · 1 line

2.43.0

Aneesh Kumar K.V (Arm)

author

2026-04-20 06:14 UTC #1 lore raw

PATCH v2 1/8 dma-direct: swiotlb: handle swiotlb alloc/free outside __dma_direct_alloc_pages

Move swiotlb allocation out of __dma_direct_alloc_pages() and handle it in dma_direct_alloc() / dma_direct_alloc_pages().

This is needed for follow-up changes that simplify the handling of memory encryption/decryption based on the DMA attribute flags.

swiotlb backing pages are already mapped decrypted by swiotlb_update_mem_attributes() and rmem_swiotlb_device_init(), so dma-direct should not call dma_set_decrypted() on allocation nor dma_set_encrypted() on free for swiotlb-backed memory.

Update alloc/free paths to detect swiotlb-backed pages and skip encrypt/decrypt transitions for those paths. Keep the existing highmem rejection in dma_direct_alloc_pages() for swiotlb allocations.

Only for "restricted-dma-pool", we currently set for_alloc = true, while rmem_swiotlb_device_init() decrypts the whole pool up front. This pool is typically used together with "shared-dma-pool", where the shared region is accessed after remap/ioremap and the returned address is suitable for decrypted memory access. So existing code paths remain valid.

Signed-off-by Aneesh Kumar K.V (Arm) <[email protected]>

---
 kernel/dma/direct.c | 44 +++++++++++++++++++++++++++++++++++++-------
 1 file changed, 37 insertions(+), 7 deletions(-)

kernel/dma/direct.c +37 -7

index ec887f443741..b958f150718a 100644
@@ -125,9 +125,6 @@ static struct page *__dma_direct_alloc_pages(struct device *dev, size_t size,
 
 	WARN_ON_ONCE(!PAGE_ALIGNED(size));
 
-	if (is_swiotlb_for_alloc(dev))
-		return dma_direct_alloc_swiotlb(dev, size);
-
 	gfp |= dma_direct_optimal_gfp_mask(dev, &phys_limit);
 	page = dma_alloc_contiguous(dev, size, gfp);
 	if (page) {

@@ -204,6 +201,7 @@ void *dma_direct_alloc(struct device *dev, size_t size,
 		dma_addr_t *dma_handle, gfp_t gfp, unsigned long attrs)
 {
 	bool remap = false, set_uncached = false;
+	bool mark_mem_decrypt = true;
 	struct page *page;
 	void *ret;

@@ -250,11 +248,21 @@ void *dma_direct_alloc(struct device *dev, size_t size,
 	    dma_direct_use_pool(dev, gfp))
 		return dma_direct_alloc_from_pool(dev, size, dma_handle, gfp);
 
+	if (is_swiotlb_for_alloc(dev)) {
+		page = dma_direct_alloc_swiotlb(dev, size);
+		if (page) {
+			mark_mem_decrypt = false;
+			goto setup_page;
+		}
+		return NULL;
+	}
+
 	/* we always manually zero the memory once we are done */
 	page = __dma_direct_alloc_pages(dev, size, gfp & ~__GFP_ZERO, true);
 	if (!page)
 		return NULL;
 
+setup_page:
 	/*
 	 * dma_alloc_contiguous can return highmem pages depending on a
 	 * combination the cma= arguments and per-arch setup.  These need to be

@@ -281,7 +289,7 @@ void *dma_direct_alloc(struct device *dev, size_t size,
 			goto out_free_pages;
 	} else {
 		ret = page_address(page);
-		if (dma_set_decrypted(dev, ret, size))
+		if (mark_mem_decrypt && dma_set_decrypted(dev, ret, size))
 			goto out_leak_pages;
 	}

@@ -298,7 +306,7 @@ void *dma_direct_alloc(struct device *dev, size_t size,
 	return ret;
 
 out_encrypt_pages:
-	if (dma_set_encrypted(dev, page_address(page), size))
+	if (mark_mem_decrypt && dma_set_encrypted(dev, page_address(page), size))
 		return NULL;
 out_free_pages:
 	__dma_direct_free_pages(dev, page, size);

@@ -310,6 +318,7 @@ void *dma_direct_alloc(struct device *dev, size_t size,
 void dma_direct_free(struct device *dev, size_t size,
 		void *cpu_addr, dma_addr_t dma_addr, unsigned long attrs)
 {
+	bool mark_mem_encrypted = true;
 	unsigned int page_order = get_order(size);
 
 	if ((attrs & DMA_ATTR_NO_KERNEL_MAPPING) &&

@@ -338,12 +347,15 @@ void dma_direct_free(struct device *dev, size_t size,
 	    dma_free_from_pool(dev, cpu_addr, PAGE_ALIGN(size)))
 		return;
 
+	if (swiotlb_find_pool(dev, dma_to_phys(dev, dma_addr)))
+		mark_mem_encrypted = false;
+
 	if (is_vmalloc_addr(cpu_addr)) {
 		vunmap(cpu_addr);
 	} else {
 		if (IS_ENABLED(CONFIG_ARCH_HAS_DMA_CLEAR_UNCACHED))
 			arch_dma_clear_uncached(cpu_addr, size);
-		if (dma_set_encrypted(dev, cpu_addr, size))
+		if (mark_mem_encrypted && dma_set_encrypted(dev, cpu_addr, size))
 			return;
 	}

@@ -359,6 +371,19 @@ struct page *dma_direct_alloc_pages(struct device *dev, size_t size,
 	if (force_dma_unencrypted(dev) && dma_direct_use_pool(dev, gfp))
 		return dma_direct_alloc_from_pool(dev, size, dma_handle, gfp);
 
+	if (is_swiotlb_for_alloc(dev)) {
+		page = dma_direct_alloc_swiotlb(dev, size);
+		if (!page)
+			return NULL;
+
+		if (PageHighMem(page)) {
+			swiotlb_free(dev, page, size);
+			return NULL;
+		}
+		ret = page_address(page);
+		goto setup_page;
+	}
+
 	page = __dma_direct_alloc_pages(dev, size, gfp, false);
 	if (!page)
 		return NULL;

@@ -366,6 +391,7 @@ struct page *dma_direct_alloc_pages(struct device *dev, size_t size,
 	ret = page_address(page);
 	if (dma_set_decrypted(dev, ret, size))
 		goto out_leak_pages;
+setup_page:
 	memset(ret, 0, size);
 	*dma_handle = phys_to_dma_direct(dev, page_to_phys(page));
 	return page;

@@ -378,13 +404,17 @@ void dma_direct_free_pages(struct device *dev, size_t size,
 		enum dma_data_direction dir)
 {
 	void *vaddr = page_address(page);
+	bool mark_mem_encrypted = true;
 
 	/* If cpu_addr is not from an atomic pool, dma_free_from_pool() fails */
 	if (IS_ENABLED(CONFIG_DMA_COHERENT_POOL) &&
 	    dma_free_from_pool(dev, vaddr, size))
 		return;
 
-	if (dma_set_encrypted(dev, vaddr, size))
+	if (swiotlb_find_pool(dev, page_to_phys(page)))
+		mark_mem_encrypted = false;
+
+	if (mark_mem_encrypted && dma_set_encrypted(dev, vaddr, size))
 		return;
 	__dma_direct_free_pages(dev, page, size);
 }

Signature · 1 line

2.43.0

Aneesh Kumar K.V (Arm)

author

2026-04-20 06:14 UTC #2 lore raw

PATCH v2 2/8 dma-direct: use DMA_ATTR_CC_SHARED in alloc/free paths

In reply to Aneesh Kumar K.V (Arm)

Propagate force_dma_unencrypted() into DMA_ATTR_CC_SHARED in the dma-direct allocation path and use the attribute to drive the related decisions.

This updates dma_direct_alloc(), dma_direct_free(), and dma_direct_alloc_pages() to fold the forced unencrypted case into attrs.

Signed-off-by Aneesh Kumar K.V (Arm) <[email protected]>

---
 kernel/dma/direct.c | 44 ++++++++++++++++++++++++++++++++++++--------
 1 file changed, 36 insertions(+), 8 deletions(-)

kernel/dma/direct.c +36 -8

index b958f150718a..0c2e1f8436ce 100644
@@ -201,16 +201,31 @@ void *dma_direct_alloc(struct device *dev, size_t size,
 		dma_addr_t *dma_handle, gfp_t gfp, unsigned long attrs)
 {
 	bool remap = false, set_uncached = false;
-	bool mark_mem_decrypt = true;
+	bool mark_mem_decrypt = false;
 	struct page *page;
 	void *ret;
 
+	/*
+	 * DMA_ATTR_CC_SHARED is not a caller-visible dma_alloc_*()
+	 * attribute. The direct allocator uses it internally after it has
+	 * decided that the backing pages must be shared/decrypted, so the
+	 * rest of the allocation path can consistently select DMA addresses,
+	 * choose compatible pools and restore encryption on free.
+	 */
+	if (attrs & DMA_ATTR_CC_SHARED)
+		return NULL;
+
+	if (force_dma_unencrypted(dev)) {
+		attrs |= DMA_ATTR_CC_SHARED;
+		mark_mem_decrypt = true;
+	}
+
 	size = PAGE_ALIGN(size);
 	if (attrs & DMA_ATTR_NO_WARN)
 		gfp |= __GFP_NOWARN;
 
-	if ((attrs & DMA_ATTR_NO_KERNEL_MAPPING) &&
-	    !force_dma_unencrypted(dev) && !is_swiotlb_for_alloc(dev))
+	if (((attrs & (DMA_ATTR_NO_KERNEL_MAPPING | DMA_ATTR_CC_SHARED)) ==
+	     DMA_ATTR_NO_KERNEL_MAPPING) && !is_swiotlb_for_alloc(dev))
 		return dma_direct_alloc_no_mapping(dev, size, dma_handle, gfp);
 
 	if (!dev_is_dma_coherent(dev)) {

@@ -244,7 +259,7 @@ void *dma_direct_alloc(struct device *dev, size_t size,
 	 * Remapping or decrypting memory may block, allocate the memory from
 	 * the atomic pools instead if we aren't allowed block.
 	 */
-	if ((remap || force_dma_unencrypted(dev)) &&
+	if ((remap || (attrs & DMA_ATTR_CC_SHARED)) &&
 	    dma_direct_use_pool(dev, gfp))
 		return dma_direct_alloc_from_pool(dev, size, dma_handle, gfp);

@@ -318,11 +333,20 @@ void *dma_direct_alloc(struct device *dev, size_t size,
 void dma_direct_free(struct device *dev, size_t size,
 		void *cpu_addr, dma_addr_t dma_addr, unsigned long attrs)
 {
-	bool mark_mem_encrypted = true;
+	bool mark_mem_encrypted = false;
 	unsigned int page_order = get_order(size);
 
-	if ((attrs & DMA_ATTR_NO_KERNEL_MAPPING) &&
-	    !force_dma_unencrypted(dev) && !is_swiotlb_for_alloc(dev)) {
+	/*
+	 * if the device had requested for an unencrypted buffer,
+	 * convert it to encrypted on free
+	 */
+	if (force_dma_unencrypted(dev)) {
+		attrs |= DMA_ATTR_CC_SHARED;
+		mark_mem_encrypted = true;
+	}
+
+	if (((attrs & (DMA_ATTR_NO_KERNEL_MAPPING | DMA_ATTR_CC_SHARED)) ==
+	     DMA_ATTR_NO_KERNEL_MAPPING) && !is_swiotlb_for_alloc(dev)) {
 		/* cpu_addr is a struct page cookie, not a kernel address */
 		dma_free_contiguous(dev, cpu_addr, size);
 		return;

@@ -365,10 +389,14 @@ void dma_direct_free(struct device *dev, size_t size,
 struct page *dma_direct_alloc_pages(struct device *dev, size_t size,
 		dma_addr_t *dma_handle, enum dma_data_direction dir, gfp_t gfp)
 {
+	unsigned long attrs = 0;
 	struct page *page;
 	void *ret;
 
-	if (force_dma_unencrypted(dev) && dma_direct_use_pool(dev, gfp))
+	if (force_dma_unencrypted(dev))
+		attrs |= DMA_ATTR_CC_SHARED;
+
+	if ((attrs & DMA_ATTR_CC_SHARED) && dma_direct_use_pool(dev, gfp))
 		return dma_direct_alloc_from_pool(dev, size, dma_handle, gfp);
 
 	if (is_swiotlb_for_alloc(dev)) {

Signature · 1 line

2.43.0

Aneesh Kumar K.V (Arm)

author

2026-04-20 06:14 UTC #3 lore raw

PATCH v2 3/8 dma-pool: track decrypted atomic pools and select them via attrs

In reply to Aneesh Kumar K.V (Arm)

Teach the atomic DMA pool code to distinguish between encrypted and decrypted pools, and make pool allocation select the matching pool based on DMA attributes.

Introduce a dma_gen_pool wrapper that records whether a pool is decrypted, initialize that state when the atomic pools are created, and use it when expanding and resizing the pools. Update dma_alloc_from_pool() to take attrs and skip pools whose encrypted/decrypted state does not match DMA_ATTR_CC_SHARED. Update dma_free_from_pool() accordingly.

Also pass DMA_ATTR_CC_SHARED from the swiotlb atomic allocation path so decrypted swiotlb allocations are taken from the correct atomic pool.

Signed-off-by Aneesh Kumar K.V (Arm) <[email protected]>

---
 drivers/iommu/dma-iommu.c   |   2 +-
 include/linux/dma-map-ops.h |   2 +-
 kernel/dma/direct.c         |  11 ++-
 kernel/dma/pool.c           | 154 +++++++++++++++++++++++-------------
 kernel/dma/swiotlb.c        |   2 +
 5 files changed, 109 insertions(+), 62 deletions(-)

drivers/iommu/dma-iommu.c +1 -1

index 54d96e847f16..c2595bee3d41 100644
@@ -1673,7 +1673,7 @@ void *iommu_dma_alloc(struct device *dev, size_t size, dma_addr_t *handle,
 	if (IS_ENABLED(CONFIG_DMA_DIRECT_REMAP) &&
 	    !gfpflags_allow_blocking(gfp) && !coherent)
 		page = dma_alloc_from_pool(dev, PAGE_ALIGN(size), &cpu_addr,
-					       gfp, NULL);
+					   gfp, attrs, NULL);
 	else
 		cpu_addr = iommu_dma_alloc_pages(dev, size, &page, gfp, attrs);
 	if (!cpu_addr)

include/linux/dma-map-ops.h +1 -1

index 6a1832a73cad..696b2c3a2305 100644
@@ -212,7 +212,7 @@ void *dma_common_pages_remap(struct page **pages, size_t size, pgprot_t prot,
 void dma_common_free_remap(void *cpu_addr, size_t size);
 
 struct page *dma_alloc_from_pool(struct device *dev, size_t size,
-		void **cpu_addr, gfp_t flags,
+		void **cpu_addr, gfp_t flags, unsigned long attrs,
 		bool (*phys_addr_ok)(struct device *, phys_addr_t, size_t));
 bool dma_free_from_pool(struct device *dev, void *start, size_t size);

kernel/dma/direct.c +7 -4

index 0c2e1f8436ce..707d410b3669 100644
@@ -162,7 +162,7 @@ static bool dma_direct_use_pool(struct device *dev, gfp_t gfp)
 }
 
 static void *dma_direct_alloc_from_pool(struct device *dev, size_t size,
-		dma_addr_t *dma_handle, gfp_t gfp)
+		dma_addr_t *dma_handle, gfp_t gfp, unsigned long attrs)
 {
 	struct page *page;
 	u64 phys_limit;

@@ -172,7 +172,8 @@ static void *dma_direct_alloc_from_pool(struct device *dev, size_t size,
 		return NULL;
 
 	gfp |= dma_direct_optimal_gfp_mask(dev, &phys_limit);
-	page = dma_alloc_from_pool(dev, size, &ret, gfp, dma_coherent_ok);
+	page = dma_alloc_from_pool(dev, size, &ret, gfp, attrs,
+				  dma_coherent_ok);
 	if (!page)
 		return NULL;
 	*dma_handle = phys_to_dma_direct(dev, page_to_phys(page));

@@ -261,7 +262,8 @@ void *dma_direct_alloc(struct device *dev, size_t size,
 	 */
 	if ((remap || (attrs & DMA_ATTR_CC_SHARED)) &&
 	    dma_direct_use_pool(dev, gfp))
-		return dma_direct_alloc_from_pool(dev, size, dma_handle, gfp);
+		return dma_direct_alloc_from_pool(dev, size, dma_handle,
+					  gfp, attrs);
 
 	if (is_swiotlb_for_alloc(dev)) {
 		page = dma_direct_alloc_swiotlb(dev, size);

@@ -397,7 +399,8 @@ struct page *dma_direct_alloc_pages(struct device *dev, size_t size,
 		attrs |= DMA_ATTR_CC_SHARED;
 
 	if ((attrs & DMA_ATTR_CC_SHARED) && dma_direct_use_pool(dev, gfp))
-		return dma_direct_alloc_from_pool(dev, size, dma_handle, gfp);
+		return dma_direct_alloc_from_pool(dev, size, dma_handle,
+					  gfp, attrs);
 
 	if (is_swiotlb_for_alloc(dev)) {
 		page = dma_direct_alloc_swiotlb(dev, size);

kernel/dma/pool.c +98 ~~-56~~

253 lines not on this page · raw message

kernel/dma/swiotlb.c +2 -0

index 1abd3e6146f4..b215b274a873 100644
@@ -623,7 +623,9 @@ static struct page *swiotlb_alloc_tlb(struct device *dev, size_t bytes,
 		if (!IS_ENABLED(CONFIG_DMA_COHERENT_POOL))
 			return NULL;
 
+		/* considered decrypted by default */
 		return dma_alloc_from_pool(dev, bytes, &vaddr, gfp,
+					   DMA_ATTR_CC_SHARED,
 					   dma_coherent_ok);
 	}

Signature · 1 line

2.43.0

Aneesh Kumar K.V (Arm)

author

2026-04-20 06:14 UTC #4 lore raw

PATCH v2 4/8 dma: swiotlb: track pool encryption state and honor DMA_ATTR_CC_SHARED

In reply to Aneesh Kumar K.V (Arm)

Teach swiotlb to distinguish between encrypted and decrypted bounce buffer pools, and make allocation and mapping paths select a pool whose state matches the requested DMA attributes.

Add a decrypted flag to io_tlb_mem, initialize it for the default and restricted pools, and propagate DMA_ATTR_CC_SHARED into swiotlb pool allocation. Reject swiotlb alloc/map requests when the selected pool does not match the required encrypted/decrypted state.

Also return DMA addresses with the matching phys_to_dma_{encrypted, unencrypted} helper so the DMA address encoding stays consistent with the chosen pool.

Signed-off-by Aneesh Kumar K.V (Arm) <[email protected]>

---
 include/linux/dma-direct.h | 10 +++++
 include/linux/swiotlb.h    |  7 ++-
 kernel/dma/direct.c        | 14 ++++--
 kernel/dma/swiotlb.c       | 89 ++++++++++++++++++++++++++++++--------
 4 files changed, 95 insertions(+), 25 deletions(-)

include/linux/dma-direct.h +10 -0

index c249912456f9..94fad4e7c11e 100644
@@ -77,6 +77,10 @@ static inline dma_addr_t dma_range_map_max(const struct bus_dma_region *map)
 #ifndef phys_to_dma_unencrypted
 #define phys_to_dma_unencrypted		phys_to_dma
 #endif
+
+#ifndef phys_to_dma_encrypted
+#define phys_to_dma_encrypted		phys_to_dma
+#endif
 #else
 static inline dma_addr_t __phys_to_dma(struct device *dev, phys_addr_t paddr)
 {

@@ -90,6 +94,12 @@ static inline dma_addr_t phys_to_dma_unencrypted(struct device *dev,
 {
 	return dma_addr_unencrypted(__phys_to_dma(dev, paddr));
 }
+
+static inline dma_addr_t phys_to_dma_encrypted(struct device *dev,
+		phys_addr_t paddr)
+{
+	return dma_addr_encrypted(__phys_to_dma(dev, paddr));
+}
 /*
  * If memory encryption is supported, phys_to_dma will set the memory encryption
  * bit in the DMA address, and dma_to_phys will clear it.

include/linux/swiotlb.h +5 -2

index 3dae0f592063..382753ba3f06 100644
@@ -111,6 +111,7 @@ struct io_tlb_mem {
 	struct dentry *debugfs;
 	bool force_bounce;
 	bool for_alloc;
+	bool decrypted;
 #ifdef CONFIG_SWIOTLB_DYNAMIC
 	bool can_grow;
 	u64 phys_limit;

@@ -282,7 +283,8 @@ static inline void swiotlb_sync_single_for_cpu(struct device *dev,
 extern void swiotlb_print_info(void);
 
 #ifdef CONFIG_DMA_RESTRICTED_POOL
-struct page *swiotlb_alloc(struct device *dev, size_t size);
+struct page *swiotlb_alloc(struct device *dev, size_t size,
+		unsigned long attrs);
 bool swiotlb_free(struct device *dev, struct page *page, size_t size);
 
 static inline bool is_swiotlb_for_alloc(struct device *dev)

@@ -290,7 +292,8 @@ static inline bool is_swiotlb_for_alloc(struct device *dev)
 	return dev->dma_io_tlb_mem->for_alloc;
 }
 #else
-static inline struct page *swiotlb_alloc(struct device *dev, size_t size)
+static inline struct page *swiotlb_alloc(struct device *dev, size_t size,
+		unsigned long attrs)
 {
 	return NULL;
 }

kernel/dma/direct.c +10 -4

index 707d410b3669..9373b9dcfb7b 100644
@@ -104,9 +104,10 @@ static void __dma_direct_free_pages(struct device *dev, struct page *page,
 	dma_free_contiguous(dev, page, size);
 }
 
-static struct page *dma_direct_alloc_swiotlb(struct device *dev, size_t size)
+static struct page *dma_direct_alloc_swiotlb(struct device *dev, size_t size,
+		unsigned long attrs)
 {
-	struct page *page = swiotlb_alloc(dev, size);
+	struct page *page = swiotlb_alloc(dev, size, attrs);
 
 	if (page && !dma_coherent_ok(dev, page_to_phys(page), size)) {
 		swiotlb_free(dev, page, size);

@@ -266,8 +267,12 @@ void *dma_direct_alloc(struct device *dev, size_t size,
 					  gfp, attrs);
 
 	if (is_swiotlb_for_alloc(dev)) {
-		page = dma_direct_alloc_swiotlb(dev, size);
+		page = dma_direct_alloc_swiotlb(dev, size, attrs);
 		if (page) {
+			/*
+			 * swiotlb allocations comes from pool already marked
+			 * decrypted
+			 */
 			mark_mem_decrypt = false;
 			goto setup_page;
 		}

@@ -374,6 +379,7 @@ void dma_direct_free(struct device *dev, size_t size,
 		return;
 
 	if (swiotlb_find_pool(dev, dma_to_phys(dev, dma_addr)))
+		/* Swiotlb doesn't need a page attribute update on free */
 		mark_mem_encrypted = false;
 
 	if (is_vmalloc_addr(cpu_addr)) {

@@ -403,7 +409,7 @@ struct page *dma_direct_alloc_pages(struct device *dev, size_t size,
 					  gfp, attrs);
 
 	if (is_swiotlb_for_alloc(dev)) {
-		page = dma_direct_alloc_swiotlb(dev, size);
+		page = dma_direct_alloc_swiotlb(dev, size, attrs);
 		if (!page)
 			return NULL;

kernel/dma/swiotlb.c +70 ~~-19~~

214 lines not on this page · raw message

Signature · 1 line

2.43.0

Aneesh Kumar K.V (Arm)

author

2026-04-20 06:14 UTC #5 lore raw

PATCH v2 5/8 dma-mapping: make dma_pgprot() honor DMA_ATTR_CC_SHARED

In reply to Aneesh Kumar K.V (Arm)

Fold encrypted/decrypted pgprot selection into dma_pgprot() so callers do not need to adjust the page protection separately.

Update dma_pgprot() to apply pgprot_decrypted() when DMA_ATTR_CC_SHARED is set and pgprot_encrypted() otherwise Convert the dma-direct allocation and mmap paths to pass DMA_ATTR_CC_SHARED instead of open-coding force_dma_unencrypted() handling around dma_pgprot().

Signed-off-by Aneesh Kumar K.V (Arm) <[email protected]>

---
 kernel/dma/direct.c  |  8 +++-----
 kernel/dma/mapping.c | 16 ++++++++++++----
 2 files changed, 15 insertions(+), 9 deletions(-)

kernel/dma/direct.c +3 -5

index 9373b9dcfb7b..a4aa7e1df2bb 100644
@@ -298,9 +298,6 @@ void *dma_direct_alloc(struct device *dev, size_t size,
 	if (remap) {
 		pgprot_t prot = dma_pgprot(dev, PAGE_KERNEL, attrs);
 
-		if (force_dma_unencrypted(dev))
-			prot = pgprot_decrypted(prot);
-
 		/* remove any dirty cache lines on the kernel alias */
 		arch_dma_prep_coherent(page, size);

@@ -603,9 +600,10 @@ int dma_direct_mmap(struct device *dev, struct vm_area_struct *vma,
 	unsigned long pfn = PHYS_PFN(dma_to_phys(dev, dma_addr));
 	int ret = -ENXIO;
 
-	vma->vm_page_prot = dma_pgprot(dev, vma->vm_page_prot, attrs);
 	if (force_dma_unencrypted(dev))
-		vma->vm_page_prot = pgprot_decrypted(vma->vm_page_prot);
+		attrs |= DMA_ATTR_CC_SHARED;
+
+	vma->vm_page_prot = dma_pgprot(dev, vma->vm_page_prot, attrs);
 
 	if (dma_mmap_from_dev_coherent(dev, vma, cpu_addr, size, &ret))
 		return ret;

kernel/dma/mapping.c +12 -4

index 23ed8eb9233e..44f715f3aa2d 100644
@@ -543,13 +543,21 @@ EXPORT_SYMBOL(dma_get_sgtable_attrs);
  */
 pgprot_t dma_pgprot(struct device *dev, pgprot_t prot, unsigned long attrs)
 {
+	pgprot_t dma_prot;
+
 	if (dev_is_dma_coherent(dev))
-		return prot;
+		dma_prot = prot;
 #ifdef CONFIG_ARCH_HAS_DMA_WRITE_COMBINE
-	if (attrs & DMA_ATTR_WRITE_COMBINE)
-		return pgprot_writecombine(prot);
+	else if (attrs & DMA_ATTR_WRITE_COMBINE)
+		dma_prot = pgprot_writecombine(prot);
 #endif
-	return pgprot_dmacoherent(prot);
+	else
+		dma_prot = pgprot_dmacoherent(prot);
+
+	if (attrs & DMA_ATTR_CC_SHARED)
+		return pgprot_decrypted(dma_prot);
+	else
+		return pgprot_encrypted(dma_prot);
 }
 #endif /* CONFIG_MMU */

Signature · 1 line

2.43.0

Aneesh Kumar K.V (Arm)

author

2026-04-20 06:15 UTC #6 lore raw

PATCH v2 6/8 dma-direct: make dma_direct_map_phys() honor DMA_ATTR_CC_SHARED

In reply to Aneesh Kumar K.V (Arm)

Teach dma_direct_map_phys() to select the DMA address encoding based on DMA_ATTR_CC_SHARED.

Use phys_to_dma_unencrypted() for decrypted mappings and phys_to_dma_encrypted() otherwise. If a device requires unencrypted DMA but the source physical address is still encrypted, force the mapping through swiotlb so the DMA address and backing memory attributes remain consistent.

Signed-off-by Aneesh Kumar K.V (Arm) <[email protected]>

---
 kernel/dma/direct.h | 25 ++++++++++++++-----------
 1 file changed, 14 insertions(+), 11 deletions(-)

kernel/dma/direct.h +14 ~~-11~~

index 7140c208c123..928671ef01e9 100644
@@ -86,9 +86,14 @@ static inline dma_addr_t dma_direct_map_phys(struct device *dev,
 		phys_addr_t phys, size_t size, enum dma_data_direction dir,
 		unsigned long attrs, bool flush)
 {
+	bool force_swiotlb_map = false;
 	dma_addr_t dma_addr;
 
-	if (is_swiotlb_force_bounce(dev)) {
+	/* if phys addr attribute is encrypted but the device is forcing an encrypted dma addr */
+	if (!(attrs & DMA_ATTR_CC_SHARED) && force_dma_unencrypted(dev))
+		force_swiotlb_map = true;
+
+	if (is_swiotlb_force_bounce(dev) || force_swiotlb_map) {
 		if (!(attrs & DMA_ATTR_CC_SHARED)) {
 			if (attrs & (DMA_ATTR_MMIO | DMA_ATTR_REQUIRE_COHERENT))
 				return DMA_MAPPING_ERROR;

@@ -105,18 +110,16 @@ static inline dma_addr_t dma_direct_map_phys(struct device *dev,
 			goto err_overflow;
 	} else if (attrs & DMA_ATTR_CC_SHARED) {
 		dma_addr = phys_to_dma_unencrypted(dev, phys);
-		if (unlikely(!dma_capable(dev, dma_addr, size, false)))
-			goto err_overflow;
 	} else {
-		dma_addr = phys_to_dma(dev, phys);
-		if (unlikely(!dma_capable(dev, dma_addr, size, true)) ||
-		    dma_kmalloc_needs_bounce(dev, size, dir)) {
-			if (is_swiotlb_active(dev) &&
-			    !(attrs & DMA_ATTR_REQUIRE_COHERENT))
-				return swiotlb_map(dev, phys, size, dir, attrs);
+		dma_addr = phys_to_dma_encrypted(dev, phys);
+	}
 
-			goto err_overflow;
-		}
+	if (unlikely(!dma_capable(dev, dma_addr, size, true)) ||
+	    dma_kmalloc_needs_bounce(dev, size, dir)) {
+		if (is_swiotlb_active(dev) &&
+		    !(attrs & DMA_ATTR_REQUIRE_COHERENT))
+			return swiotlb_map(dev, phys, size, dir, attrs);
+		goto err_overflow;
 	}
 
 	if (!dev_is_dma_coherent(dev) &&

Signature · 1 line

2.43.0

Aneesh Kumar K.V (Arm)

author

2026-04-20 06:15 UTC #12 lore raw

PATCH v2 7/8 dma-direct: set decrypted flag for remapped DMA allocations

In reply to Aneesh Kumar K.V (Arm)

Devices that are DMA non-coherent and require a remap were skipping dma_set_decrypted(), leaving DMA buffers encrypted even when the device requires unencrypted access. Move the call after the if (remap) branch so that both the direct and remapped allocation paths correctly mark the allocation as decrypted (or fail cleanly) before use.

Architectures such as arm64 cannot mark vmap addresses as decrypted, and highmem pages necessarily require a vmap remap. As a result, such allocations cannot be safely used for unencrypted DMA. Therefore, when an unencrypted DMA buffer is requested, avoid allocating high PFNs from __dma_direct_alloc_pages().

Other architectures (e.g. x86) do not have this limitation. However, rather than making this architecture-specific, apply the restriction only when the device requires unencrypted DMA access, for simplicity.

Fixes f3c962226dbe ("dma-direct: clean up the remapping checks in dma_direct_alloc")

Signed-off-by Aneesh Kumar K.V (Arm) <[email protected]>

---
 kernel/dma/direct.c | 30 +++++++++++++++++++++++++++---
 1 file changed, 27 insertions(+), 3 deletions(-)

kernel/dma/direct.c +27 -3

index a4aa7e1df2bb..63a7b7bfff97 100644
@@ -204,6 +204,7 @@ void *dma_direct_alloc(struct device *dev, size_t size,
 {
 	bool remap = false, set_uncached = false;
 	bool mark_mem_decrypt = false;
+	bool allow_highmem = true;
 	struct page *page;
 	void *ret;

@@ -222,6 +223,15 @@ void *dma_direct_alloc(struct device *dev, size_t size,
 		mark_mem_decrypt = true;
 	}
 
+	if (attrs & DMA_ATTR_CC_SHARED)
+		/*
+		 * Unencrypted/shared DMA requires a linear-mapped buffer
+		 * address to look up the PFN and set architecture-required PFN
+		 * attributes. This is not possible with HighMem. Avoid HighMem
+		 * allocation.
+		 */
+		allow_highmem = false;
+
 	size = PAGE_ALIGN(size);
 	if (attrs & DMA_ATTR_NO_WARN)
 		gfp |= __GFP_NOWARN;

@@ -280,7 +290,7 @@ void *dma_direct_alloc(struct device *dev, size_t size,
 	}
 
 	/* we always manually zero the memory once we are done */
-	page = __dma_direct_alloc_pages(dev, size, gfp & ~__GFP_ZERO, true);
+	page = __dma_direct_alloc_pages(dev, size, gfp & ~__GFP_ZERO, allow_highmem);
 	if (!page)
 		return NULL;

@@ -308,7 +318,13 @@ void *dma_direct_alloc(struct device *dev, size_t size,
 			goto out_free_pages;
 	} else {
 		ret = page_address(page);
-		if (mark_mem_decrypt && dma_set_decrypted(dev, ret, size))
+	}
+
+	if (mark_mem_decrypt) {
+		void *lm_addr;
+
+		lm_addr = page_address(page);
+		if (set_memory_decrypted((unsigned long)lm_addr, PFN_UP(size)))
 			goto out_leak_pages;
 	}

@@ -384,8 +400,16 @@ void dma_direct_free(struct device *dev, size_t size,
 	} else {
 		if (IS_ENABLED(CONFIG_ARCH_HAS_DMA_CLEAR_UNCACHED))
 			arch_dma_clear_uncached(cpu_addr, size);
-		if (mark_mem_encrypted && dma_set_encrypted(dev, cpu_addr, size))
+	}
+
+	if (mark_mem_encrypted) {
+		void *lm_addr;
+
+		lm_addr = phys_to_virt(dma_to_phys(dev, dma_addr));
+		if (set_memory_encrypted((unsigned long)lm_addr, PFN_UP(size))) {
+			pr_warn_ratelimited("leaking DMA memory that can't be re-encrypted\n");
 			return;
+		}
 	}
 
 	__dma_direct_free_pages(dev, dma_direct_to_page(dev, dma_addr), size);

Signature · 1 line

2.43.0

Aneesh Kumar K.V (Arm)

author

2026-04-20 06:15 UTC #17 lore raw

PATCH v2 8/8 dma-direct: select DMA address encoding from DMA_ATTR_CC_SHARED

In reply to Aneesh Kumar K.V (Arm)

Make the dma-direct helpers derive the DMA address encoding from DMA_ATTR_CC_SHARED instead of implicitly relying on force_dma_unencrypted() inside phys_to_dma_direct()

Pass an explicit unencrypted/decrypted state into phys_to_dma_direct(), make the alloc paths return DMA addresses that match the requested buffer encryption state. Also only call dma_set_decrypted() DMA_ATTR_CC_SHARED is actually set.

Signed-off-by Aneesh Kumar K.V (Arm) <[email protected]>

---
 kernel/dma/direct.c | 48 ++++++++++++++++++++++++++++-----------------
 1 file changed, 30 insertions(+), 18 deletions(-)

kernel/dma/direct.c +30 ~~-18~~

index 63a7b7bfff97..1239344f8585 100644
@@ -24,11 +24,11 @@
 u64 zone_dma_limit __ro_after_init = DMA_BIT_MASK(24);
 
 static inline dma_addr_t phys_to_dma_direct(struct device *dev,
-		phys_addr_t phys)
+		phys_addr_t phys, bool unencrypted)
 {
-	if (force_dma_unencrypted(dev))
+	if (unencrypted)
 		return phys_to_dma_unencrypted(dev, phys);
-	return phys_to_dma(dev, phys);
+	return phys_to_dma_encrypted(dev, phys);
 }
 
 static inline struct page *dma_direct_to_page(struct device *dev,

@@ -39,8 +39,9 @@ static inline struct page *dma_direct_to_page(struct device *dev,
 
 u64 dma_direct_get_required_mask(struct device *dev)
 {
+	bool require_decrypted = force_dma_unencrypted(dev);
 	phys_addr_t phys = (phys_addr_t)(max_pfn - 1) << PAGE_SHIFT;
-	u64 max_dma = phys_to_dma_direct(dev, phys);
+	u64 max_dma = phys_to_dma_direct(dev, phys, require_decrypted);
 
 	return (1ULL << (fls64(max_dma) - 1)) * 2 - 1;
 }

@@ -69,7 +70,8 @@ static gfp_t dma_direct_optimal_gfp_mask(struct device *dev, u64 *phys_limit)
 
 bool dma_coherent_ok(struct device *dev, phys_addr_t phys, size_t size)
 {
-	dma_addr_t dma_addr = phys_to_dma_direct(dev, phys);
+	bool require_decrypted = force_dma_unencrypted(dev);
+	dma_addr_t dma_addr = phys_to_dma_direct(dev, phys, require_decrypted);
 
 	if (dma_addr == DMA_MAPPING_ERROR)
 		return false;

@@ -79,17 +81,18 @@ bool dma_coherent_ok(struct device *dev, phys_addr_t phys, size_t size)
 
 static int dma_set_decrypted(struct device *dev, void *vaddr, size_t size)
 {
-	if (!force_dma_unencrypted(dev))
-		return 0;
-	return set_memory_decrypted((unsigned long)vaddr, PFN_UP(size));
+	int ret;
+
+	ret = set_memory_decrypted((unsigned long)vaddr, PFN_UP(size));
+	if (ret)
+		pr_warn_ratelimited("leaking DMA memory that can't be decrypted\n");
+	return ret;
 }
 
 static int dma_set_encrypted(struct device *dev, void *vaddr, size_t size)
 {
 	int ret;
 
-	if (!force_dma_unencrypted(dev))
-		return 0;
 	ret = set_memory_encrypted((unsigned long)vaddr, PFN_UP(size));
 	if (ret)
 		pr_warn_ratelimited("leaking DMA memory that can't be re-encrypted\n");

@@ -177,7 +180,8 @@ static void *dma_direct_alloc_from_pool(struct device *dev, size_t size,
 				  dma_coherent_ok);
 	if (!page)
 		return NULL;
-	*dma_handle = phys_to_dma_direct(dev, page_to_phys(page));
+	*dma_handle = phys_to_dma_direct(dev, page_to_phys(page),
+					 !!(attrs & DMA_ATTR_CC_SHARED));
 	return ret;
 }

@@ -193,9 +197,11 @@ static void *dma_direct_alloc_no_mapping(struct device *dev, size_t size,
 	/* remove any dirty cache lines on the kernel alias */
 	if (!PageHighMem(page))
 		arch_dma_prep_coherent(page, size);
-
-	/* return the page pointer as the opaque cookie */
-	*dma_handle = phys_to_dma_direct(dev, page_to_phys(page));
+	/*
+	 * return the page pointer as the opaque cookie.
+	 * Never used for unencrypted allocation
+	 */
+	*dma_handle = phys_to_dma_encrypted(dev, page_to_phys(page));
 	return page;
 }

@@ -337,7 +343,8 @@ void *dma_direct_alloc(struct device *dev, size_t size,
 			goto out_encrypt_pages;
 	}
 
-	*dma_handle = phys_to_dma_direct(dev, page_to_phys(page));
+	*dma_handle = phys_to_dma_direct(dev, page_to_phys(page),
+					 !!(attrs & DMA_ATTR_CC_SHARED));
 	return ret;
 
 out_encrypt_pages:

@@ -447,11 +454,12 @@ struct page *dma_direct_alloc_pages(struct device *dev, size_t size,
 		return NULL;
 
 	ret = page_address(page);
-	if (dma_set_decrypted(dev, ret, size))
+	if ((attrs & DMA_ATTR_CC_SHARED) && dma_set_decrypted(dev, ret, size))
 		goto out_leak_pages;
 setup_page:
 	memset(ret, 0, size);
-	*dma_handle = phys_to_dma_direct(dev, page_to_phys(page));
+	*dma_handle = phys_to_dma_direct(dev, page_to_phys(page),
+					 !!(attrs & DMA_ATTR_CC_SHARED));
 	return page;
 out_leak_pages:
 	return NULL;

@@ -461,8 +469,12 @@ void dma_direct_free_pages(struct device *dev, size_t size,
 		struct page *page, dma_addr_t dma_addr,
 		enum dma_data_direction dir)
 {
+	/*
+	 * if the device had requested for an unencrypted buffer,
+	 * convert it to encrypted on free
+	 */
+	bool mark_mem_encrypted =  force_dma_unencrypted(dev);
 	void *vaddr = page_address(page);
-	bool mark_mem_encrypted = true;
 
 	/* If cpu_addr is not from an atomic pool, dma_free_from_pool() fails */
 	if (IS_ENABLED(CONFIG_DMA_COHERENT_POOL) &&

Signature · 1 line

2.43.0

Jason Gunthorpe

2026-04-21 12:29 UTC #7 lore raw

Re: [PATCH v2 6/8] dma-direct: make dma_direct_map_phys() honor DMA_ATTR_CC_SHARED

In reply to Aneesh Kumar K.V (Arm)

Quoted 19 lines · Aneesh Kumar K.V (Arm)

Teach dma_direct_map_phys() to select the DMA address encoding based on DMA_ATTR_CC_SHARED.
Use phys_to_dma_unencrypted() for decrypted mappings and phys_to_dma_encrypted() otherwise. If a device requires unencrypted DMA but the source physical address is still encrypted, force the mapping through swiotlb so the DMA address and backing memory attributes remain consistent.
Signed-off-by Aneesh Kumar K.V (Arm) <[email protected]>
---
 kernel/dma/direct.h | 25 ++++++++++++++-----------
 1 file changed, 14 insertions(+), 11 deletions(-)
kernel/dma/direct.h +0 -0
index 7140c208c123..928671ef01e9 100644

kernel/dma/direct.h static inline dma_addr_t dma_direct_map_phys(struct device *dev, · line 94

Quoted 10 lines

kernel/dma/direct.h +4 -1

@@ -86,9 +86,14 @@ static inline dma_addr_t dma_direct_map_phys(struct device *dev,
 		phys_addr_t phys, size_t size, enum dma_data_direction dir,
 		unsigned long attrs, bool flush)
 {
+	bool force_swiotlb_map = false;
 	dma_addr_t dma_addr;
 
-	if (is_swiotlb_force_bounce(dev)) {
+	/* if phys addr attribute is encrypted but the device is forcing an encrypted dma addr */
+	if (!(attrs & DMA_ATTR_CC_SHARED) && force_dma_unencrypted(dev))
+		force_swiotlb_map = true;

continuing my prior email.. This is really in the wrong spot, it should be in dma_capable()

Quoted 5 lines

kernel/dma/direct.h +1 -0

+	if (is_swiotlb_force_bounce(dev) || force_swiotlb_map) {
 		if (!(attrs & DMA_ATTR_CC_SHARED)) {
 			if (attrs & (DMA_ATTR_MMIO | DMA_ATTR_REQUIRE_COHERENT))
 				return DMA_MAPPING_ERROR;

kernel/dma/direct.h static inline dma_addr_t dma_direct_map_phys(struct device *dev, · line 113

Quoted 9 lines

kernel/dma/direct.h +0 -5

@@ -105,18 +110,16 @@ static inline dma_addr_t dma_direct_map_phys(struct device *dev,
 			goto err_overflow;
 	} else if (attrs & DMA_ATTR_CC_SHARED) {
 		dma_addr = phys_to_dma_unencrypted(dev, phys);
-		if (unlikely(!dma_capable(dev, dma_addr, size, false)))
-			goto err_overflow;
 	} else {
-		dma_addr = phys_to_dma(dev, phys);
-		if (unlikely(!dma_capable(dev, dma_addr, size, true)) ||
-		    dma_kmalloc_needs_bounce(dev, size, dir)) {

here.

swiotlb because the device can't reach a high address and swiotlb because the device doesn't have T=1 are really the same thing and should have the same code flow.

Add attrs to dma_capable() and check force_dma_unencrypted(dev) inside.

Quoted 5 lines

kernel/dma/direct.h +2 -3

-			if (is_swiotlb_active(dev) &&
-			    !(attrs & DMA_ATTR_REQUIRE_COHERENT))
-				return swiotlb_map(dev, phys, size, dir, attrs);
+		dma_addr = phys_to_dma_encrypted(dev, phys);
+	}

kernel/dma/direct.h static inline dma_addr_t dma_direct_map_phys(struct device *dev, · line 123

Quoted 10 lines

kernel/dma/direct.h +6 -2

 
-			goto err_overflow;
-		}
+	if (unlikely(!dma_capable(dev, dma_addr, size, true)) ||
+	    dma_kmalloc_needs_bounce(dev, size, dir)) {
+		if (is_swiotlb_active(dev) &&
+		    !(attrs & DMA_ATTR_REQUIRE_COHERENT))
+			return swiotlb_map(dev, phys, size, dir, attrs);
+		goto err_overflow;
 	}

Then this movement shouldn't be needed?

Jason

Jason Gunthorpe

2026-04-21 12:34 UTC #13 lore raw

Re: [PATCH v2 7/8] dma-direct: set decrypted flag for remapped DMA allocations

In reply to Aneesh Kumar K.V (Arm)

Quoted 8 lines · Aneesh Kumar K.V (Arm)

Devices that are DMA non-coherent and require a remap were skipping dma_set_decrypted(), leaving DMA buffers encrypted even when the device requires unencrypted access. Move the call after the if (remap) branch so that both the direct and remapped allocation paths correctly mark the allocation as decrypted (or fail cleanly) before use.
Architectures such as arm64 cannot mark vmap addresses as decrypted, and highmem pages necessarily require a vmap remap.

I don't think I saw an aswer for this, why can't arm accept pgprot_decrypted() for vmap? It really should, I don't think we should have these minor pointless arch differences.

Suzuki? You mentioned it, can you elaborate?

Jason

Jason Gunthorpe

2026-04-21 12:40 UTC #18 lore raw

In reply to Aneesh Kumar K.V (Arm)

Quoted 10 lines · Aneesh Kumar K.V (Arm)

This series propagates DMA_ATTR_CC_SHARED through the dma-direct, dma-pool, and swiotlb paths so that encrypted and decrypted DMA buffers are handled consistently.
Today, the direct DMA path mostly relies on force_dma_unencrypted() for shared/decrypted buffer handling. This series consolidates the force_dma_unencrypted() checks in the top-level functions and ensures that the remaining DMA interfaces use DMA attributes to make the correct decisions.

Quoted 14 lines

The series:
- moves swiotlb-backed allocations out of __dma_direct_alloc_pages(),
- propagates DMA_ATTR_CC_SHARED through the dma-direct alloc/free paths,
- teaches the atomic DMA pools to track encrypted versus decrypted state,
- tracks swiotlb pool encryption state and enforces strict pool selection,
- centralizes encrypted/decrypted pgprot handling in dma_pgprot() using DMA attributes,
- makes dma_direct_map_phys() choose the DMA address encoding from attrs, and
- uses the selected swiotlb pool state to derive the returned DMA address.

I think this is very reasonable looking.

Jason

Suzuki K Poulose

2026-04-21 12:54 UTC #14 lore raw

Re: [PATCH v2 7/8] dma-direct: set decrypted flag for remapped DMA allocations

In reply to Jason Gunthorpe

Quoted 7 lines · Jason Gunthorpe

Quoted 6 lines · Aneesh Kumar K.V (Arm)
Devices that are DMA non-coherent and require a remap were skipping dma_set_decrypted(), leaving DMA buffers encrypted even when the device requires unencrypted access. Move the call after the if (remap) branch so that both the direct and remapped allocation paths correctly mark the allocation as decrypted (or fail cleanly) before use.

Quoted 8 lines

Quoted 2 lines
Architectures such as arm64 cannot mark vmap addresses as decrypted, and highmem pages necessarily require a vmap remap.
I don't think I saw an aswer for this, why can't arm accept pgprot_decrypted() for vmap? It really should, I don't think we should have these minor pointless arch differences.
Suzuki? You mentioned it, can you elaborate?

We can accept pgprot_decrypted(), but this must be done carefully as the backing pages must be first converted to "decrypted" in the linear map (set_memory_decrypted()).

With that in place, it should be fine. It is, set_memory_decrypted(vmalloc_address) is we don't support.

Cheers
Suzuki

Quoted 2 lines

Jason

Jason Gunthorpe

2026-04-21 13:53 UTC #15 lore raw

Re: [PATCH v2 7/8] dma-direct: set decrypted flag for remapped DMA allocations

Quoted 15 lines · Suzuki K Poulose

Quoted 14 lines · Jason Gunthorpe
Quoted 8 lines · Aneesh Kumar K.V (Arm)
Devices that are DMA non-coherent and require a remap were skipping dma_set_decrypted(), leaving DMA buffers encrypted even when the device requires unencrypted access. Move the call after the if (remap) branch so that both the direct and remapped allocation paths correctly mark the allocation as decrypted (or fail cleanly) before use.
Architectures such as arm64 cannot mark vmap addresses as decrypted, and highmem pages necessarily require a vmap remap.
I don't think I saw an aswer for this, why can't arm accept pgprot_decrypted() for vmap? It really should, I don't think we should have these minor pointless arch differences.

Quoted 5 lines

Quoted 1 line
Suzuki? You mentioned it, can you elaborate?
We can accept pgprot_decrypted(), but this must be done carefully as the backing pages must be first converted to "decrypted" in the linear map (set_memory_decrypted()).

Isn't that the case for any use of pgprot_decrypted? I think that is fine and followed by the dma api.

Quoted 2 lines

With that in place, it should be fine. It is, set_memory_decrypted(vmalloc_address) is we don't support.

That makes more sense. Nothing should do that, changing the state of memory that is mapped any place other than the linear map is not allowed. I understand this is the condition where Intel will machine check..

So with that clarification at least the commit message should be revised in this patch to not mention vmap.

Jason

Aneesh Kumar K.V

author

2026-04-22 05:24 UTC #16 lore raw

Re: [PATCH v2 7/8] dma-direct: set decrypted flag for remapped DMA allocations

Quoted 28 lines · Jason Gunthorpe

Quoted 15 lines · Suzuki K Poulose
Quoted 14 lines · Jason Gunthorpe
Quoted 8 lines · Aneesh Kumar K.V (Arm)
Devices that are DMA non-coherent and require a remap were skipping dma_set_decrypted(), leaving DMA buffers encrypted even when the device requires unencrypted access. Move the call after the if (remap) branch so that both the direct and remapped allocation paths correctly mark the allocation as decrypted (or fail cleanly) before use.
Architectures such as arm64 cannot mark vmap addresses as decrypted, and highmem pages necessarily require a vmap remap.
I don't think I saw an aswer for this, why can't arm accept pgprot_decrypted() for vmap? It really should, I don't think we should have these minor pointless arch differences.
Quoted 5 lines
Quoted 1 line
Suzuki? You mentioned it, can you elaborate?
We can accept pgprot_decrypted(), but this must be done carefully as the backing pages must be first converted to "decrypted" in the linear map (set_memory_decrypted()).
Isn't that the case for any use of pgprot_decrypted? I think that is fine and followed by the dma api.
Quoted 2 lines
With that in place, it should be fine. It is, set_memory_decrypted(vmalloc_address) is we don't support.

Quoted 8 lines

That makes more sense. Nothing should do that, changing the state of memory that is mapped any place other than the linear map is not allowed. I understand this is the condition where Intel will machine check..
So with that clarification at least the commit message should be revised in this patch to not mention vmap.

I will update the commit message to clarify this further.

-aneesh

Aneesh Kumar K.V

author

2026-04-22 05:50 UTC #8 lore raw

Re: [PATCH v2 6/8] dma-direct: make dma_direct_map_phys() honor DMA_ATTR_CC_SHARED

In reply to Jason Gunthorpe

Quoted 51 lines · Jason Gunthorpe

Quoted 19 lines · Aneesh Kumar K.V (Arm)
Teach dma_direct_map_phys() to select the DMA address encoding based on DMA_ATTR_CC_SHARED.
Use phys_to_dma_unencrypted() for decrypted mappings and phys_to_dma_encrypted() otherwise. If a device requires unencrypted DMA but the source physical address is still encrypted, force the mapping through swiotlb so the DMA address and backing memory attributes remain consistent.
Signed-off-by Aneesh Kumar K.V (Arm) <[email protected]>
---
 kernel/dma/direct.h | 25 ++++++++++++++-----------
 1 file changed, 14 insertions(+), 11 deletions(-)
kernel/dma/direct.h +0 -0
index 7140c208c123..928671ef01e9 100644
kernel/dma/direct.h static inline dma_addr_t dma_direct_map_phys(struct device *dev, · line 94
Quoted 10 lines
kernel/dma/direct.h +4 -1
@@ -86,9 +86,14 @@ static inline dma_addr_t dma_direct_map_phys(struct device *dev,
 		phys_addr_t phys, size_t size, enum dma_data_direction dir,
 		unsigned long attrs, bool flush)
 {
+	bool force_swiotlb_map = false;
 	dma_addr_t dma_addr;
 
-	if (is_swiotlb_force_bounce(dev)) {
+	/* if phys addr attribute is encrypted but the device is forcing an encrypted dma addr */
+	if (!(attrs & DMA_ATTR_CC_SHARED) && force_dma_unencrypted(dev))
+		force_swiotlb_map = true;
continuing my prior email.. This is really in the wrong spot, it should be in dma_capable()
Quoted 5 lines
kernel/dma/direct.h +1 -0
+	if (is_swiotlb_force_bounce(dev) || force_swiotlb_map) {
 		if (!(attrs & DMA_ATTR_CC_SHARED)) {
 			if (attrs & (DMA_ATTR_MMIO | DMA_ATTR_REQUIRE_COHERENT))
 				return DMA_MAPPING_ERROR;
kernel/dma/direct.h static inline dma_addr_t dma_direct_map_phys(struct device *dev, · line 113
Quoted 9 lines
kernel/dma/direct.h +0 -5
@@ -105,18 +110,16 @@ static inline dma_addr_t dma_direct_map_phys(struct device *dev,
 			goto err_overflow;
 	} else if (attrs & DMA_ATTR_CC_SHARED) {
 		dma_addr = phys_to_dma_unencrypted(dev, phys);
-		if (unlikely(!dma_capable(dev, dma_addr, size, false)))
-			goto err_overflow;
 	} else {
-		dma_addr = phys_to_dma(dev, phys);
-		if (unlikely(!dma_capable(dev, dma_addr, size, true)) ||
-		    dma_kmalloc_needs_bounce(dev, size, dir)) {
here.

Quoted 7 lines

swiotlb because the device can't reach a high address and swiotlb because the device doesn't have T=1 are really the same thing and should have the same code flow.
Add attrs to dma_capable() and check force_dma_unencrypted(dev) inside.

will update in the next revision

Quoted 7 lines

kernel/dma/direct.h +2 -3

-			if (is_swiotlb_active(dev) &&
-			    !(attrs & DMA_ATTR_REQUIRE_COHERENT))
-				return swiotlb_map(dev, phys, size, dir, attrs);
+		dma_addr = phys_to_dma_encrypted(dev, phys);
+	}

Quoted 11 lines

kernel/dma/direct.h static inline dma_addr_t dma_direct_map_phys(struct device *dev, · line 123
Quoted 9 lines
kernel/dma/direct.h +6 -2
-			goto err_overflow;
-		}
+	if (unlikely(!dma_capable(dev, dma_addr, size, true)) ||
+	    dma_kmalloc_needs_bounce(dev, size, dir)) {
+		if (is_swiotlb_active(dev) &&
+		    !(attrs & DMA_ATTR_REQUIRE_COHERENT))
+			return swiotlb_map(dev, phys, size, dir, attrs);
+		goto err_overflow;
 	}
Then this movement shouldn't be needed?

I am still not clear about the use of DMA_ATTR_CC_SHARED here. If the resulting DMA address is not dma_capable, I was expecting that we should fall back to swiotlb_map(). That was the intention behind this change. However, the other email thread suggests that DMA_ATTR_CC_SHARED is always used with swiotlb_force_bounce(). I think we should address that. If we do, the goal here would be to check dma_capable for both shared and private addresses.

For private/protected addresses, swiotlb_map() will currently fail with DMA_MAPPING_ERROR because the default io_tlb_mem (dev->dma_io_tlb_mem) is decrypted by default

-aneesh

Aneesh Kumar K.V

author

2026-04-22 06:16 UTC #9 lore raw

Re: [PATCH v2 6/8] dma-direct: make dma_direct_map_phys() honor DMA_ATTR_CC_SHARED

Quoted 90 lines · Aneesh Kumar K.V

Quoted 51 lines · Jason Gunthorpe
Quoted 19 lines · Aneesh Kumar K.V (Arm)
Teach dma_direct_map_phys() to select the DMA address encoding based on DMA_ATTR_CC_SHARED.
Use phys_to_dma_unencrypted() for decrypted mappings and phys_to_dma_encrypted() otherwise. If a device requires unencrypted DMA but the source physical address is still encrypted, force the mapping through swiotlb so the DMA address and backing memory attributes remain consistent.
Signed-off-by Aneesh Kumar K.V (Arm) <[email protected]>
---
 kernel/dma/direct.h | 25 ++++++++++++++-----------
 1 file changed, 14 insertions(+), 11 deletions(-)
kernel/dma/direct.h +0 -0
index 7140c208c123..928671ef01e9 100644
kernel/dma/direct.h static inline dma_addr_t dma_direct_map_phys(struct device *dev, · line 94
Quoted 10 lines
kernel/dma/direct.h +4 -1
@@ -86,9 +86,14 @@ static inline dma_addr_t dma_direct_map_phys(struct device *dev,
 		phys_addr_t phys, size_t size, enum dma_data_direction dir,
 		unsigned long attrs, bool flush)
 {
+	bool force_swiotlb_map = false;
 	dma_addr_t dma_addr;
 
-	if (is_swiotlb_force_bounce(dev)) {
+	/* if phys addr attribute is encrypted but the device is forcing an encrypted dma addr */
+	if (!(attrs & DMA_ATTR_CC_SHARED) && force_dma_unencrypted(dev))
+		force_swiotlb_map = true;
continuing my prior email.. This is really in the wrong spot, it should be in dma_capable()
Quoted 5 lines
kernel/dma/direct.h +1 -0
+	if (is_swiotlb_force_bounce(dev) || force_swiotlb_map) {
 		if (!(attrs & DMA_ATTR_CC_SHARED)) {
 			if (attrs & (DMA_ATTR_MMIO | DMA_ATTR_REQUIRE_COHERENT))
 				return DMA_MAPPING_ERROR;
kernel/dma/direct.h static inline dma_addr_t dma_direct_map_phys(struct device *dev, · line 113
Quoted 9 lines
kernel/dma/direct.h +0 -5
@@ -105,18 +110,16 @@ static inline dma_addr_t dma_direct_map_phys(struct device *dev,
 			goto err_overflow;
 	} else if (attrs & DMA_ATTR_CC_SHARED) {
 		dma_addr = phys_to_dma_unencrypted(dev, phys);
-		if (unlikely(!dma_capable(dev, dma_addr, size, false)))
-			goto err_overflow;
 	} else {
-		dma_addr = phys_to_dma(dev, phys);
-		if (unlikely(!dma_capable(dev, dma_addr, size, true)) ||
-		    dma_kmalloc_needs_bounce(dev, size, dir)) {
here.
Quoted 7 lines
swiotlb because the device can't reach a high address and swiotlb because the device doesn't have T=1 are really the same thing and should have the same code flow.
Add attrs to dma_capable() and check force_dma_unencrypted(dev) inside.
will update in the next revision
Quoted 7 lines
Quoted 7 lines
kernel/dma/direct.h +2 -3
-			if (is_swiotlb_active(dev) &&
-			    !(attrs & DMA_ATTR_REQUIRE_COHERENT))
-				return swiotlb_map(dev, phys, size, dir, attrs);
+		dma_addr = phys_to_dma_encrypted(dev, phys);
+	}
 
Quoted 11 lines
kernel/dma/direct.h static inline dma_addr_t dma_direct_map_phys(struct device *dev, · line 123
Quoted 9 lines
kernel/dma/direct.h +6 -2
-			goto err_overflow;
-		}
+	if (unlikely(!dma_capable(dev, dma_addr, size, true)) ||
+	    dma_kmalloc_needs_bounce(dev, size, dir)) {
+		if (is_swiotlb_active(dev) &&
+		    !(attrs & DMA_ATTR_REQUIRE_COHERENT))
+			return swiotlb_map(dev, phys, size, dir, attrs);
+		goto err_overflow;
 	}
Then this movement shouldn't be needed?
I am still not clear about the use of DMA_ATTR_CC_SHARED here. If the resulting DMA address is not dma_capable, I was expecting that we should fall back to swiotlb_map(). That was the intention behind this change. However, the other email thread suggests that DMA_ATTR_CC_SHARED is always used with swiotlb_force_bounce(). I think we should address that. If we do, the goal here would be to check dma_capable for both shared and private addresses.

Quoted 3 lines

For private/protected addresses, swiotlb_map() will currently fail with DMA_MAPPING_ERROR because the default io_tlb_mem (dev->dma_io_tlb_mem) is decrypted by default

Also note that if a DMA_ATTR_CC_SHARED DMA address is not dma_capable, then swiotlb_map() will most likely fail as well. We do check the resulting SWIOTLB-mapped address again in swiotlb_map(). That is, if a DMA_ATTR_CC_SHARED physical address fails because the resulting DMA address exceeds the DMA mask (due to phys_to_dma_unencrypted() adding the top bit), then the SWIOTLB-mapped DMA address will likely fail the capability check for the same reason, as it would also include the top bit.

So, if we want, we could avoid moving that if condition. However, IMHO, we could make it more generic to indicate that if any address is not DMA-capable, and if a SWIOTLB is active, we should attempt swiotlb_map()

-aneesh

Jason Gunthorpe

2026-04-24 22:41 UTC #11 lore raw

Re: [PATCH v2 6/8] dma-direct: make dma_direct_map_phys() honor DMA_ATTR_CC_SHARED

In reply to Aneesh Kumar K.V

Quoted 18 lines · Aneesh Kumar K.V

Quoted 6 lines

kernel/dma/direct.h +2 -3

-			if (is_swiotlb_active(dev) &&
-			    !(attrs & DMA_ATTR_REQUIRE_COHERENT))
-				return swiotlb_map(dev, phys, size, dir, attrs);
+		dma_addr = phys_to_dma_encrypted(dev, phys);
+	}

Quoted 11 lines

kernel/dma/direct.h static inline dma_addr_t dma_direct_map_phys(struct device *dev, · line 123
Quoted 9 lines
kernel/dma/direct.h +6 -2
-			goto err_overflow;
-		}
+	if (unlikely(!dma_capable(dev, dma_addr, size, true)) ||
+	    dma_kmalloc_needs_bounce(dev, size, dir)) {
+		if (is_swiotlb_active(dev) &&
+		    !(attrs & DMA_ATTR_REQUIRE_COHERENT))
+			return swiotlb_map(dev, phys, size, dir, attrs);
+		goto err_overflow;
 	}
Then this movement shouldn't be needed?

Quoted 3 lines

I am still not clear about the use of DMA_ATTR_CC_SHARED here. If the resulting DMA address is not dma_capable, I was expecting that we should fall back to swiotlb_map().

"resulting" ? From what?

The user provides an address. If the provided address is marked DMA_ATTR_CC_SHARED, then dma_capable should succeed on a CC system. Otherwise if !DMA_ATTR_CC_SHARED dma_capable must require T=1, or fail if T=0.

Quoted 5 lines

That was the intention behind this change.
However, the other email thread suggests that DMA_ATTR_CC_SHARED is always used with swiotlb_force_bounce(). I think we should address that. If we do, the goal here would be to check dma_capable for both shared and private addresses.

The flow I think should be

if (force swiotlb)
then do swiotlb

if (!dma_capable())
then do swiotlb

if (kmalloc_needs_bounce())
then do swiotlb

otherwise use the provided phys_addr directly

ie stop using force swiotlb to handle T=0, instead have dma_capable directly check T together with DMA_ATTR_CC_SHARED.

Quoted 3 lines

For private/protected addresses, swiotlb_map() will currently fail with DMA_MAPPING_ERROR because the default io_tlb_mem (dev->dma_io_tlb_mem) is decrypted by default

This is a bug in swiotlb. swiotlb must *always* returns something that is usable by the device, or it is broken. ie the pa it picks must pass dma_capable:

It must return a buffer that falls within the dma mask

It must return an unprotected buffer if the device is T=0

It must return a protected buffer if the device is T=1 (ie it should not choose an unprotected buffer just because DMA_ATTR_CC_SHARED, we might be bouncing because the device dma mask can't reach the unprotected adress space)

So, when the device is switched to T=1 something also has to go and fix swiotlb so it is using T=1 memory too, and there should be defensive WARN_ONs in the swiotlb path that the memory it picked is suitable.

Jason

Jason Gunthorpe

2026-04-24 22:45 UTC #10 lore raw

Re: [PATCH v2 6/8] dma-direct: make dma_direct_map_phys() honor DMA_ATTR_CC_SHARED

In reply to Aneesh Kumar K.V

Quoted 2 lines · Aneesh Kumar K.V

Also note that if a DMA_ATTR_CC_SHARED DMA address is not dma_capable, then swiotlb_map() will most likely fail as well.

Well, thats OK, frankly the platform is broken if it can't provide low addresses that pass the dma mask check through swiotlb.

Quoted 6 lines

We do check the resulting SWIOTLB-mapped address again in swiotlb_map(). That is, if a DMA_ATTR_CC_SHARED physical address fails because the resulting DMA address exceeds the DMA mask (due to phys_to_dma_unencrypted() adding the top bit), then the SWIOTLB-mapped DMA address will likely fail the capability check for the same reason, as it would also include the top bit.

Yes, platform is broken, no option but to fail.

Quoted 4 lines

So, if we want, we could avoid moving that if condition. However, IMHO, we could make it more generic to indicate that if any address is not DMA-capable, and if a SWIOTLB is active, we should attempt swiotlb_map()

Yes that is how it should flow, the task falls to swiotlb to find a usable address.

Hopefully platform people have done smart things and T=0 devices have low addresses for unprotected memory and T=1 devices have low address for private memory.

To make this work swiotlb will have to bounce into low address private memory to achieve working DMA.

Jason

Mostafa Saleh

Tested-by on the v2 series

2026-06-02 14:25 UTC #19 lore raw

In reply to Aneesh Kumar K.V (Arm)

Quoted 9 lines · Aneesh Kumar K.V (Arm)

This series propagates DMA_ATTR_CC_SHARED through the dma-direct, dma-pool, and swiotlb paths so that encrypted and decrypted DMA buffers are handled consistently.
Today, the direct DMA path mostly relies on force_dma_unencrypted() for shared/decrypted buffer handling. This series consolidates the force_dma_unencrypted() checks in the top-level functions and ensures that the remaining DMA interfaces use DMA attributes to make the correct decisions.

I tested this series on protected KVM and did not see regressions.

Tested-by Mostafa Saleh <[email protected]>

Next, I will:
- Send the pKVM CC patch separately.
- Review this series.

Thanks,
Mostafa

Quoted 47 lines

The series:
- moves swiotlb-backed allocations out of __dma_direct_alloc_pages(),
- propagates DMA_ATTR_CC_SHARED through the dma-direct alloc/free paths,
- teaches the atomic DMA pools to track encrypted versus decrypted state,
- tracks swiotlb pool encryption state and enforces strict pool selection,
- centralizes encrypted/decrypted pgprot handling in dma_pgprot() using DMA attributes,
- makes dma_direct_map_phys() choose the DMA address encoding from attrs, and
- uses the selected swiotlb pool state to derive the returned DMA address.
Changes from v1:
* rebased to latest kernel (change from DMA_ATTR_CC_DECRYPTED -> DMA_ATTR_CC_SHARED)
* Update alloc path such that DMA_ATTR_CC_SHARED s not a caller-visible attribute.
Aneesh Kumar K.V (Arm) (8):
dma-direct: swiotlb: handle swiotlb alloc/free outside
__dma_direct_alloc_pages
dma-direct: use DMA_ATTR_CC_SHARED in alloc/free paths
dma-pool: track decrypted atomic pools and select them via attrs
dma: swiotlb: track pool encryption state and honor DMA_ATTR_CC_SHARED
dma-mapping: make dma_pgprot() honor DMA_ATTR_CC_SHARED
dma-direct: make dma_direct_map_phys() honor DMA_ATTR_CC_SHARED
dma-direct: set decrypted flag for remapped DMA allocations
dma-direct: select DMA address encoding from DMA_ATTR_CC_SHARED
 drivers/iommu/dma-iommu.c   |   2 +-
 include/linux/dma-direct.h  |  10 ++
 include/linux/dma-map-ops.h |   2 +-
 include/linux/swiotlb.h     |   7 +-
 kernel/dma/direct.c         | 185 ++++++++++++++++++++++++++++--------
 kernel/dma/direct.h         |  25 ++---
 kernel/dma/mapping.c        |  16 +++-
 kernel/dma/pool.c           | 154 +++++++++++++++++++-----------
 kernel/dma/swiotlb.c        |  89 +++++++++++++----
 9 files changed, 355 insertions(+), 135 deletions(-)
base-commit: c1f49dea2b8f335813d3b348fd39117fb8efb428
Signature · 1 line
2.43.0

Mostafa Saleh

2026-06-02 14:29 UTC #20 lore raw

Quoted 6 lines · Mostafa Saleh

Quoted 4 lines · Aneesh Kumar K.V (Arm)
This series propagates DMA_ATTR_CC_SHARED through the dma-direct, dma-pool, and swiotlb paths so that encrypted and decrypted DMA buffers are handled consistently.

Quoted 9 lines

Quoted 5 lines
Today, the direct DMA path mostly relies on force_dma_unencrypted() for shared/decrypted buffer handling. This series consolidates the force_dma_unencrypted() checks in the top-level functions and ensures that the remaining DMA interfaces use DMA attributes to make the correct decisions.
I tested this series on protected KVM and did not see regressions.
Tested-by Mostafa Saleh <[email protected]>

Sorry, that was supposed to be for v5:
https://lore.kernel.org/all/[email protected]/

Thanks,
Mostafa

Quoted 54 lines

Next, I will:
- Send the pKVM CC patch separately.
- Review this series.
Thanks,
Mostafa
Quoted 47 lines
The series:
- moves swiotlb-backed allocations out of __dma_direct_alloc_pages(),
- propagates DMA_ATTR_CC_SHARED through the dma-direct alloc/free paths,
- teaches the atomic DMA pools to track encrypted versus decrypted state,
- tracks swiotlb pool encryption state and enforces strict pool selection,
- centralizes encrypted/decrypted pgprot handling in dma_pgprot() using DMA attributes,
- makes dma_direct_map_phys() choose the DMA address encoding from attrs, and
- uses the selected swiotlb pool state to derive the returned DMA address.
Changes from v1:
* rebased to latest kernel (change from DMA_ATTR_CC_DECRYPTED -> DMA_ATTR_CC_SHARED)
* Update alloc path such that DMA_ATTR_CC_SHARED s not a caller-visible attribute.
Aneesh Kumar K.V (Arm) (8):
dma-direct: swiotlb: handle swiotlb alloc/free outside
__dma_direct_alloc_pages
dma-direct: use DMA_ATTR_CC_SHARED in alloc/free paths
dma-pool: track decrypted atomic pools and select them via attrs
dma: swiotlb: track pool encryption state and honor DMA_ATTR_CC_SHARED
dma-mapping: make dma_pgprot() honor DMA_ATTR_CC_SHARED
dma-direct: make dma_direct_map_phys() honor DMA_ATTR_CC_SHARED
dma-direct: set decrypted flag for remapped DMA allocations
dma-direct: select DMA address encoding from DMA_ATTR_CC_SHARED
 drivers/iommu/dma-iommu.c   |   2 +-
 include/linux/dma-direct.h  |  10 ++
 include/linux/dma-map-ops.h |   2 +-
 include/linux/swiotlb.h     |   7 +-
 kernel/dma/direct.c         | 185 ++++++++++++++++++++++++++++--------
 kernel/dma/direct.h         |  25 ++---
 kernel/dma/mapping.c        |  16 +++-
 kernel/dma/pool.c           | 154 +++++++++++++++++++-----------
 kernel/dma/swiotlb.c        |  89 +++++++++++++----
 9 files changed, 355 insertions(+), 135 deletions(-)
base-commit: c1f49dea2b8f335813d3b348fd39117fb8efb428 --
2.43.0

Aneesh Kumar K.V

author

2026-06-03 04:57 UTC #21 lore raw

In reply to Mostafa Saleh

Quoted 5 lines · Mostafa Saleh

Quoted 4 lines · Aneesh Kumar K.V (Arm)
This series propagates DMA_ATTR_CC_SHARED through the dma-direct, dma-pool, and swiotlb paths so that encrypted and decrypted DMA buffers are handled consistently.

Quoted 9 lines

Quoted 5 lines
Today, the direct DMA path mostly relies on force_dma_unencrypted() for shared/decrypted buffer handling. This series consolidates the force_dma_unencrypted() checks in the top-level functions and ensures that the remaining DMA interfaces use DMA attributes to make the correct decisions.
I tested this series on protected KVM and did not see regressions.
Tested-by Mostafa Saleh <[email protected]>

Thanks, I will pick the Tested-by: for the v5 series.

Quoted 5 lines

Next, I will:
- Send the pKVM CC patch separately.
- Review this series.

I will send a v6 dropping the pkvm patch

-aneesh