[PATCH v2 10/11] coco: arm64: dma: Update force_dma_unencrypted for accepted devices

Aneesh Kumar K.V (Arm) posted 11 patches 2 weeks ago
[PATCH v2 10/11] coco: arm64: dma: Update force_dma_unencrypted for accepted devices
Posted by Aneesh Kumar K.V (Arm) 2 weeks ago
This change updates the DMA behavior for accepted devices by assuming
they access only private memory. Currently, the DMA API does not provide
a mechanism for allocating shared memory that can be accessed by both
the secure realm and the non-secure host.

Accepted devices are therefore expected to operate entirely within the
private memory space. As of now, there is no API in the DMA layer that
allows such devices to explicitly request shared memory allocations for
coherent data exchange with the host.

If future use cases require accepted devices to interact with shared
memory— for example, for host-device communication, we will need to
extend the DMA interface to support such allocation semantics. This
commit lays the groundwork for that by clearly defining the current
assumption and isolating the enforcement to force_dma_unencrypted.

Signed-off-by: Aneesh Kumar K.V (Arm) <aneesh.kumar@kernel.org>
---
 arch/arm64/include/asm/mem_encrypt.h |  6 +-----
 arch/arm64/mm/mem_encrypt.c          | 10 ++++++++++
 include/linux/swiotlb.h              |  5 +++++
 3 files changed, 16 insertions(+), 5 deletions(-)

diff --git a/arch/arm64/include/asm/mem_encrypt.h b/arch/arm64/include/asm/mem_encrypt.h
index 314b2b52025f..d77c10cd5b79 100644
--- a/arch/arm64/include/asm/mem_encrypt.h
+++ b/arch/arm64/include/asm/mem_encrypt.h
@@ -15,14 +15,10 @@ int arm64_mem_crypt_ops_register(const struct arm64_mem_crypt_ops *ops);
 
 int set_memory_encrypted(unsigned long addr, int numpages);
 int set_memory_decrypted(unsigned long addr, int numpages);
+bool force_dma_unencrypted(struct device *dev);
 
 int realm_register_memory_enc_ops(void);
 
-static inline bool force_dma_unencrypted(struct device *dev)
-{
-	return is_realm_world();
-}
-
 /*
  * For Arm CCA guests, canonical addresses are "encrypted", so no changes
  * required for dma_addr_encrypted().
diff --git a/arch/arm64/mm/mem_encrypt.c b/arch/arm64/mm/mem_encrypt.c
index ee3c0ab04384..645c099fd551 100644
--- a/arch/arm64/mm/mem_encrypt.c
+++ b/arch/arm64/mm/mem_encrypt.c
@@ -17,6 +17,7 @@
 #include <linux/compiler.h>
 #include <linux/err.h>
 #include <linux/mm.h>
+#include <linux/device.h>
 
 #include <asm/mem_encrypt.h>
 
@@ -48,3 +49,12 @@ int set_memory_decrypted(unsigned long addr, int numpages)
 	return crypt_ops->decrypt(addr, numpages);
 }
 EXPORT_SYMBOL_GPL(set_memory_decrypted);
+
+bool force_dma_unencrypted(struct device *dev)
+{
+	if (device_cc_accepted(dev))
+		return false;
+
+	return is_realm_world();
+}
+EXPORT_SYMBOL_GPL(force_dma_unencrypted);
diff --git a/include/linux/swiotlb.h b/include/linux/swiotlb.h
index 3dae0f592063..b27de03f2466 100644
--- a/include/linux/swiotlb.h
+++ b/include/linux/swiotlb.h
@@ -173,6 +173,11 @@ static inline bool is_swiotlb_force_bounce(struct device *dev)
 {
 	struct io_tlb_mem *mem = dev->dma_io_tlb_mem;
 
+	if (device_cc_accepted(dev)) {
+		dev_warn_once(dev, "(TIO) Disable SWIOTLB");
+		return false;
+	}
+
 	return mem && mem->force_bounce;
 }
 
-- 
2.43.0

Re: [PATCH v2 10/11] coco: arm64: dma: Update force_dma_unencrypted for accepted devices
Posted by Jonathan Cameron 1 week, 4 days ago
On Mon, 17 Nov 2025 19:30:06 +0530
"Aneesh Kumar K.V (Arm)" <aneesh.kumar@kernel.org> wrote:

> This change updates the DMA behavior for accepted devices by assuming
> they access only private memory. Currently, the DMA API does not provide
> a mechanism for allocating shared memory that can be accessed by both
> the secure realm and the non-secure host.
> 
> Accepted devices are therefore expected to operate entirely within the
> private memory space. As of now, there is no API in the DMA layer that
> allows such devices to explicitly request shared memory allocations for
> coherent data exchange with the host.

Isn't this sentence a bit of a repeat of the one at the end of the
1st paragraph.

> 
> If future use cases require accepted devices to interact with shared
> memory— for example, for host-device communication, we will need to
> extend the DMA interface to support such allocation semantics. This
> commit lays the groundwork for that by clearly defining the current
> assumption and isolating the enforcement to force_dma_unencrypted.
> 
> Signed-off-by: Aneesh Kumar K.V (Arm) <aneesh.kumar@kernel.org>