iommu/arm-smmu-v3: Support guest-level Realm VSMMU (Part-1)

-----Original Message-----
From: Nicolin Chen <[email protected]>
Sent: 10 September 2026 04:33
To: Jason Gunthorpe <[email protected]>; Catalin Marinas <[email protected]>; Will Deacon <[email protected]>; [email protected]; Robin Murphy <[email protected]>; [email protected]; Danilo Krummrich <[email protected]>; Marek Szyprowski <[email protected]>; [email protected]
Cc: Mark Rutland <[email protected]>; Greg Kroah-Hartman <[email protected]>; Suzuki K Poulose <[email protected]>; Gavin Shan <[email protected]>; Vikram Sethi <[email protected]>; Anshuman Khandual <[email protected]>; Shanker Donthineni <[email protected]>; Mostafa Saleh <[email protected]>; [email protected]; Thomas Huth <[email protected]>; Marc Zyngier <[email protected]>; Ryan Roberts <[email protected]>; [email protected]; Kohei Enju <[email protected]>; Shaopeng Tan <[email protected]>; Ard Biesheuvel <[email protected]>; James Morse <[email protected]>; Steven Price <[email protected]>; Sang-Heon Jeon <[email protected]>; Omar Sandoval <[email protected]>; Andrew Morton <[email protected]>; Jinjie Ruan <[email protected]>; Sam Edwards <[email protected]>; Douglas Anderson <[email protected]>; Florian Fainelli <[email protected]>; Chen-Yu Tsai <[email protected]>; Huacai Chen <[email protected]>; Thomas Zimmermann <[email protected]>; Pranjal Shrivastava <[email protected]>; Ashish Mhetre <[email protected]>; Shameer Kolothum Thodi <[email protected]>; [email protected]; linux- [email protected]; [email protected]; [email protected]; Sonang Patel <[email protected]>; Ankit Agrawal <[email protected]>
Subject: [PATCH v1 2/8] firmware: arm_rmm: Add VSMMU commands and fields

DEN0137 2.0-bet3 adds the RSI_VSMMU_GET_INFO command and replaces the old
RSI_VSMMU_ACTIVATE command with RSI_ARCH_DEV_ACTIVATE.

Add the command IDs, return codes, SMMUv3 device type, and helpers for both
commands.

Assisted-by Codex:gpt-5.6-sol

Signed-off-by Nicolin Chen <[email protected]>

---
 include/linux/arm-rsi-cmds.h  | 22 ++++++++++++++++++++++
 include/linux/arm-smccc-rsi.h | 20 ++++++++++++++++++++
 2 files changed, 42 insertions(+)

include/linux/arm-rsi-cmds.h +18 -0

index 13478e14c4296..548ab0bcac722 100644
@@ -237,4 +237,26 @@ static inline unsigned long
 rsi_attestation_token_continue(phys_addr_t granule,
 	return res.a0;
 }
 
+static inline unsigned long rsi_vsmmu_get_info(phys_addr_t addr,
+					       phys_addr_t *top)
+{
+	struct arm_smccc_res res;
+
+	arm_smccc_1_1_invoke(SMC_RSI_VSMMU_GET_INFO, addr, &res);
+	if (res.a0 == RSI_SUCCESS && top)
+		*top = res.a1;
+
+	return res.a0;
+}
+
+static inline unsigned long rsi_arch_dev_activate(phys_addr_t base,
+						  unsigned long dev_type)
+{
+	struct arm_smccc_res res;
+
+	arm_smccc_1_1_invoke(SMC_RSI_ARCH_DEV_ACTIVATE, base,

dev_type, &res);

Quoted 7 lines

include/linux/arm-rsi-cmds.h +6 -0

+static inline unsigned long rsi_arch_dev_activate(phys_addr_t base,
+						  unsigned long dev_type)
+{
+	struct arm_smccc_res res;
+
+	arm_smccc_1_1_invoke(SMC_RSI_ARCH_DEV_ACTIVATE, base,

dev_type, &res);

These calls leave unused input registers unspecified, whereas DEN0137 bet3 B1.2 marks them SBZ. Could we explicitly zero them?

"On calling an RMI or RSI command, any of X1- X16 which are not
specified as input values in the command definition SBZ"

Quoted 11 lines · Shameer Kolothum Thodi

Quoted 7 lines

include/linux/arm-rsi-cmds.h +6 -0

+static inline unsigned long rsi_arch_dev_activate(phys_addr_t base,
+						  unsigned long dev_type)
+{
+	struct arm_smccc_res res;
+
+	arm_smccc_1_1_invoke(SMC_RSI_ARCH_DEV_ACTIVATE, base,

dev_type, &res);

These calls leave unused input registers unspecified, whereas DEN0137 bet3 B1.2 marks them SBZ. Could we explicitly zero them?

Quoted 2 lines

"On calling an RMI or RSI command, any of X1- X16 which are not
specified as input values in the command definition SBZ"

That seems too broad, Linux doesn't even support the x8-x16 inputs in the macros. I think the spec has errd here.

Requiring zeroing of x0-x7 is sort of reasonable. Any future use of x8-x16 (including outputs) should require a direct opt in of the OS to indicate it supports this bank of registers.

Otherwise you probably need a new macro helper for this protocol..

-----Original Message-----
From: Nicolin Chen <[email protected]>
Sent: 28 October 2026 18:38
To: Jason Gunthorpe <[email protected]>
Cc: Shameer Kolothum Thodi <[email protected]>; Catalin Marinas <[email protected]>; Will Deacon <[email protected]>; [email protected]; Robin Murphy <[email protected]>; [email protected]; Danilo Krummrich <[email protected]>; Marek Szyprowski <[email protected]>; [email protected]; Mark Rutland <[email protected]>; Greg Kroah-Hartman <[email protected]>; Suzuki K Poulose <[email protected]>; Gavin Shan <[email protected]>; Vikram Sethi <[email protected]>; Anshuman Khandual <[email protected]>; Shanker Donthineni <[email protected]>; Mostafa Saleh <[email protected]>; [email protected]; Thomas Huth <[email protected]>; Marc Zyngier <[email protected]>; Ryan Roberts <[email protected]>; [email protected]; Kohei Enju <[email protected]>; Shaopeng Tan <[email protected]>; Ard Biesheuvel <[email protected]>; James Morse <[email protected]>; Steven Price <[email protected]>; Sang-Heon Jeon <[email protected]>; Omar Sandoval <[email protected]>; Andrew Morton <[email protected]>; Jinjie Ruan <[email protected]>; Sam Edwards <[email protected]>; Douglas Anderson <[email protected]>; Florian Fainelli <[email protected]>; Chen-Yu Tsai <[email protected]>; Huacai Chen <[email protected]>; Thomas Zimmermann <[email protected]>; Pranjal Shrivastava <[email protected]>; Ashish Mhetre <[email protected]>; [email protected]; linux- [email protected]; [email protected]; [email protected]; Sonang Patel <[email protected]>; Ankit Agrawal <[email protected]>
Subject: Re: [PATCH v1 2/8] firmware: arm_rmm: Add VSMMU commands and fields

Quoted 1 line · Jason Gunthorpe

On Wed, Oct 28, 2026 at 09:49:53AM +0000, Shameer Kolothum Thodi

Quoted 21 lines · wrote:

Quoted 11 lines

Quoted 7 lines

include/linux/arm-rsi-cmds.h +6 -0

+static inline unsigned long rsi_arch_dev_activate(phys_addr_t base,
+						  unsigned long dev_type)
+{
+	struct arm_smccc_res res;
+
+	arm_smccc_1_1_invoke(SMC_RSI_ARCH_DEV_ACTIVATE, base,

dev_type, &res);

These calls leave unused input registers unspecified, whereas DEN0137 bet3 B1.2 marks them SBZ. Could we explicitly zero them?

Quoted 2 lines

"On calling an RMI or RSI command, any of X1- X16 which are not
specified as input values in the command definition SBZ"

That seems too broad, Linux doesn't even support the x8-x16 inputs in the macros. I think the spec has errd here.

Requiring zeroing of x0-x7 is sort of reasonable. Any future use of x8-x16 (including outputs) should require a direct opt in of the OS to indicate it supports this bank of registers.

Quoted 1 line

Otherwise you probably need a new macro helper for this protocol..

We could probably replace it with:
arm_smccc_smc(SMC_RSI_ARCH_DEV_ACTIVATE, base, dev_type, 0,
0, 0, 0, 0,

		      &res);

This should specify those unused inputs.

Quoted 31 lines · Jason Gunthorpe

Quoted 1 line

On Wed, Oct 28, 2026 at 09:49:53AM +0000, Shameer Kolothum Thodi

Quoted 14 lines · wrote:

Quoted 11 lines

Quoted 7 lines

include/linux/arm-rsi-cmds.h +6 -0

+static inline unsigned long rsi_arch_dev_activate(phys_addr_t base,
+						  unsigned long dev_type)
+{
+	struct arm_smccc_res res;
+
+	arm_smccc_1_1_invoke(SMC_RSI_ARCH_DEV_ACTIVATE, base,

dev_type, &res);

These calls leave unused input registers unspecified, whereas DEN0137 bet3 B1.2 marks them SBZ. Could we explicitly zero them?

Quoted 2 lines

"On calling an RMI or RSI command, any of X1- X16 which are not
specified as input values in the command definition SBZ"

Quoted 8 lines

That seems too broad, Linux doesn't even support the x8-x16 inputs in the macros. I think the spec has errd here.

Requiring zeroing of x0-x7 is sort of reasonable. Any future use of x8-x16 (including outputs) should require a direct opt in of the OS to indicate it supports this bank of registers.

Otherwise you probably need a new macro helper for this protocol..

We could probably replace it with:
arm_smccc_smc(SMC_RSI_ARCH_DEV_ACTIVATE, base, dev_type, 0,
0, 0, 0, 0,

		      &res);

Quoted 1 line

This should specify those unused inputs.

Or we could use arm_smccc_1_2_smc() with zero initialized registers, as rsi_attestation_token_init() does. I think that would cover X8-X16 too.

But other RSI wrappers don't do that consistently, so it's fine either way, I guess.

Quoted 31 lines · Shameer Kolothum Thodi

Quoted 31 lines · Jason Gunthorpe

Quoted 1 line

On Wed, Oct 28, 2026 at 09:49:53AM +0000, Shameer Kolothum Thodi

Quoted 14 lines · wrote:

Quoted 11 lines

Quoted 7 lines

include/linux/arm-rsi-cmds.h +6 -0

+static inline unsigned long rsi_arch_dev_activate(phys_addr_t base,
+						  unsigned long dev_type)
+{
+	struct arm_smccc_res res;
+
+	arm_smccc_1_1_invoke(SMC_RSI_ARCH_DEV_ACTIVATE, base,

dev_type, &res);

These calls leave unused input registers unspecified, whereas DEN0137 bet3 B1.2 marks them SBZ. Could we explicitly zero them?

Quoted 2 lines

"On calling an RMI or RSI command, any of X1- X16 which are not
specified as input values in the command definition SBZ"

Quoted 8 lines

That seems too broad, Linux doesn't even support the x8-x16 inputs in the macros. I think the spec has errd here.

Requiring zeroing of x0-x7 is sort of reasonable. Any future use of x8-x16 (including outputs) should require a direct opt in of the OS to indicate it supports this bank of registers.

Otherwise you probably need a new macro helper for this protocol..

We could probably replace it with:
arm_smccc_smc(SMC_RSI_ARCH_DEV_ACTIVATE, base, dev_type, 0,
0, 0, 0, 0,

		      &res);

Quoted 4 lines

Quoted 1 line

This should specify those unused inputs.

Or we could use arm_smccc_1_2_smc() with zero initialized registers, as rsi_attestation_token_init() does. I think that would cover X8-X16 too.

Yeah, that seems to be the right thing to do.

Quoted 2 lines

But other RSI wrappers don't do that consistently, so it's fine either way, I guess.

Seems like a bug, with the spec being specific here it should be fixed.

-----Original Message-----
From: Nicolin Chen <[email protected]>
Sent: 10 September 2026 04:33
To: Jason Gunthorpe <[email protected]>; Catalin Marinas <[email protected]>; Will Deacon <[email protected]>; [email protected]; Robin Murphy <[email protected]>; [email protected]; Danilo Krummrich <[email protected]>; Marek Szyprowski <[email protected]>; [email protected]
Cc: Mark Rutland <[email protected]>; Greg Kroah-Hartman <[email protected]>; Suzuki K Poulose <[email protected]>; Gavin Shan <[email protected]>; Vikram Sethi <[email protected]>; Anshuman Khandual <[email protected]>; Shanker Donthineni <[email protected]>; Mostafa Saleh <[email protected]>; [email protected]; Thomas Huth <[email protected]>; Marc Zyngier <[email protected]>; Ryan Roberts <[email protected]>; [email protected]; Kohei Enju <[email protected]>; Shaopeng Tan <[email protected]>; Ard Biesheuvel <[email protected]>; James Morse <[email protected]>; Steven Price <[email protected]>; Sang-Heon Jeon <[email protected]>; Omar Sandoval <[email protected]>; Andrew Morton <[email protected]>; Jinjie Ruan <[email protected]>; Sam Edwards <[email protected]>; Douglas Anderson <[email protected]>; Florian Fainelli <[email protected]>; Chen-Yu Tsai <[email protected]>; Huacai Chen <[email protected]>; Thomas Zimmermann <[email protected]>; Pranjal Shrivastava <[email protected]>; Ashish Mhetre <[email protected]>; Shameer Kolothum Thodi <[email protected]>; [email protected]; linux- [email protected]; [email protected]; [email protected]; Sonang Patel <[email protected]>; Ankit Agrawal <[email protected]>
Subject: [PATCH v1 4/8] dma-mapping: Keep DMA memory private for capable devices

Architecture code can require devices to use unencrypted memory. This makes the DMA API use shared memory for coherent allocations and bounce streaming
mappings through SWIOTLB.

A device marked with DEV_FLAG_DMA_CC_PRIVATE can reach private memory
directly. Add dma_require_decrypted() to combine force_dma_unencrypted() with the new device flag, and use it throughout the generic DMA code.

Assisted-by Codex:gpt-5.6-sol

Signed-off-by Nicolin Chen <[email protected]>

---
 include/linux/dma-direct.h |  7 ++++++-
 kernel/dma/direct.c        | 16 ++++++++--------
 kernel/dma/mapping.c       |  2 +-
 kernel/dma/swiotlb.c       |  2 +-
 4 files changed, 16 insertions(+), 11 deletions(-)

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

index daa31a1adf7b0..fb35ca27941cc 100644
@@ -134,6 +134,11 @@ static inline bool force_dma_unencrypted(struct
 device *dev)
 }
 #endif /* CONFIG_ARCH_HAS_FORCE_DMA_UNENCRYPTED */
 
+static inline bool dma_require_decrypted(struct device *dev)
+{
+	return !dev_dma_cc_private(dev) && force_dma_unencrypted(dev);
+}
+
 static inline bool dma_capable(struct device *dev, dma_addr_t addr, size_t
 size,

include/linux/dma-direct.h +1 -1

 		bool is_ram, unsigned long attrs)
 {

@@ -146,7 +151,7 @@ static inline bool dma_capable(struct device *dev,
 dma_addr_t addr, size_t size,
 	 * requires unencrypted DMA addresses. Treat it as not DMA-capable
 	 * so the caller can fall back to a suitable SWIOTLB pool.
 	 */
-	if (!(attrs & DMA_ATTR_CC_SHARED) &&
 force_dma_unencrypted(dev))
+	if (!(attrs & DMA_ATTR_CC_SHARED) &&
 dma_require_decrypted(dev))

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

 		return false;
 
 	if (is_ram && !IS_ENABLED(CONFIG_ARCH_DMA_ADDR_T_64BIT) &&

kernel/dma/direct.c +2 -2

index da665ca22d5c0..fbddab9740162 100644
@@ -41,7 +41,7 @@ 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);
+	bool require_decrypted = dma_require_decrypted(dev);
 	phys_addr_t phys = ((phys_addr_t)max_pfn << PAGE_SHIFT) - 1;
 	u64 max_dma = phys_to_dma_direct(dev, phys, require_decrypted);

@@ -72,7 +72,7 @@ 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)
 {
-	bool require_decrypted = force_dma_unencrypted(dev);
+	bool require_decrypted = dma_require_decrypted(dev);
 	dma_addr_t dma_addr = phys_to_dma_direct(dev, phys,
 require_decrypted);

kernel/dma/direct.c +3 -3

 	if (dma_addr == DMA_MAPPING_ERROR)

@@ -208,7 +208,7 @@ void *dma_direct_alloc(struct device *dev, size_t size,
 	struct page *page;
 	void *cpu_addr;
 
-	if (force_dma_unencrypted(dev))
+	if (dma_require_decrypted(dev))
 		attrs |= __DMA_ATTR_ALLOC_CC_SHARED;
 
 	if (attrs & __DMA_ATTR_ALLOC_CC_SHARED) {

@@ -368,7 +368,7 @@ void dma_direct_free(struct device *dev, size_t size,
 	 * If the allocation used decrypted/shared backing pages, restore
 	 * the encryption state on free.
 	 */
-	if (force_dma_unencrypted(dev))
+	if (dma_require_decrypted(dev))
 		attrs |= __DMA_ATTR_ALLOC_CC_SHARED;
 
 	if (attrs & __DMA_ATTR_ALLOC_CC_SHARED)

@@ -436,7 +436,7 @@ struct page *dma_direct_alloc_pages(struct device
 *dev, size_t size,
 	struct page *page;
 	void *cpu_addr;
 
-	if (force_dma_unencrypted(dev))
+	if (dma_require_decrypted(dev))
 		attrs |= __DMA_ATTR_ALLOC_CC_SHARED;
 

if ((attrs & __DMA_ATTR_ALLOC_CC_SHARED) &&
dma_direct_use_pool(dev, gfp))

kernel/dma/direct.c +1 -1

@@ -480,7 +480,7 @@ void dma_direct_free_pages(struct device *dev,
 size_t size,
 	 * if the device had requested for an unencrypted buffer,
 	 * convert it to encrypted on free
 	 */
-	bool mark_mem_encrypted = force_dma_unencrypted(dev);
+	bool mark_mem_encrypted = dma_require_decrypted(dev);
 
 	/* If page is not from an atomic pool, dma_free_from_pool_page()

fails */

kernel/dma/direct.c +1 -1

 	if (IS_ENABLED(CONFIG_DMA_COHERENT_POOL) &&

@@ -649,7 +649,7 @@ int dma_direct_mmap(struct device *dev, struct
 vm_area_struct *vma,
 	const pgoff_t pgoff_end = vma_end_pgoff(vma);
 	int ret = -ENXIO;
 
-	if (force_dma_unencrypted(dev))
+	if (dma_require_decrypted(dev))
 		attrs |= DMA_ATTR_CC_SHARED;
 

kernel/dma/direct.c +1 -1

 	vma->vm_page_prot = dma_pgprot(dev, vma->vm_page_prot, attrs);

@@ -798,7 +798,7 @@ size_t dma_direct_max_mapping_size(struct device
 *dev)
 	/* If SWIOTLB is active, use its maximum mapping size */
 	if (is_swiotlb_active(dev) &&
 	    (dma_addressing_limited(dev) || is_swiotlb_force_bounce(dev) ||
-	     force_dma_unencrypted(dev)))
+	     dma_require_decrypted(dev)))
 		return swiotlb_max_mapping_size(dev);
 

kernel/dma/direct.c +0 -0

 	return SIZE_MAX;

kernel/dma/mapping.c +1 -1

index 11c127ad45370..e7c48a925b7ac 100644
@@ -673,7 +673,7 @@ void *dma_alloc_attrs(struct device *dev, size_t size,
 dma_addr_t *dma_handle,
 		return NULL;
 	}
 
-	if (force_dma_unencrypted(dev))
+	if (dma_require_decrypted(dev))
 		attrs |= __DMA_ATTR_ALLOC_CC_SHARED;
 

if (dma_alloc_from_dev_coherent(dev, size, dma_handle,
&cpu_addr)) {

kernel/dma/swiotlb.c +0 -0

index ded7016a46a71..d08a3643ded14 100644

Quoted 4 lines

kernel/dma/swiotlb.c +0 -0

@@ -1552,7 +1552,7 @@ phys_addr_t swiotlb_tbl_map_single(struct device
 *dev, phys_addr_t orig_addr,
 	if (cc_platform_has(CC_ATTR_GUEST_MEM_ENCRYPT)) {
 

kernel/dma/swiotlb.c phys_addr_t swiotlb_tbl_map_single(struct device *dev, phys_addr_t orig_addr, · line 1555

Quoted 4 lines

kernel/dma/swiotlb.c +1 -1

 		/* swiotlb pool is incorrect for this device */
-		if (unlikely(mem->cc_shared !=
 force_dma_unencrypted(dev)))
+		if (unlikely(mem->cc_shared != dma_require_decrypted(dev)))

Just wondering, what if a device with CC_PRIVATE set has addressing limitations and needs a private bounce buffer? Or is that not a use case at all?

+ * @tdisp_t1: device uses its confidential IOMMU's T=1 stream. A zero value
+ * means T=0, where the T=1 stream remains blocked while the core
+ * owns required DMA operations such as ATS.

Quoted 3 lines · Nicolin Chen

+ * @tdisp_t1: device uses its confidential IOMMU's T=1 stream. A zero value
+ * means T=0, where the T=1 stream remains blocked while the core
+ * owns required DMA operations such as ATS.

What happens when the TDI transitions to ERROR, and how does this bit signify it?
A TDI can drop to ERROR asynchronously, and at that point the device is outside the trust boundary again.

-----Original Message-----
From: Nicolin Chen <[email protected]>
Sent: 10 September 2026 04:33
To: Jason Gunthorpe <[email protected]>; Catalin Marinas <[email protected]>; Will Deacon <[email protected]>; [email protected]; Robin Murphy <[email protected]>; [email protected]; Danilo Krummrich <[email protected]>; Marek Szyprowski <[email protected]>; [email protected]
Cc: Mark Rutland <[email protected]>; Greg Kroah-Hartman <[email protected]>; Suzuki K Poulose <[email protected]>; Gavin Shan <[email protected]>; Vikram Sethi <[email protected]>; Anshuman Khandual <[email protected]>; Shanker Donthineni <[email protected]>; Mostafa Saleh <[email protected]>; [email protected]; Thomas Huth <[email protected]>; Marc Zyngier <[email protected]>; Ryan Roberts <[email protected]>; [email protected]; Kohei Enju <[email protected]>; Shaopeng Tan <[email protected]>; Ard Biesheuvel <[email protected]>; James Morse <[email protected]>; Steven Price <[email protected]>; Sang-Heon Jeon <[email protected]>; Omar Sandoval <[email protected]>; Andrew Morton <[email protected]>; Jinjie Ruan <[email protected]>; Sam Edwards <[email protected]>; Douglas Anderson <[email protected]>; Florian Fainelli <[email protected]>; Chen-Yu Tsai <[email protected]>; Huacai Chen <[email protected]>; Thomas Zimmermann <[email protected]>; Pranjal Shrivastava <[email protected]>; Ashish Mhetre <[email protected]>; Shameer Kolothum Thodi <[email protected]>; [email protected]; linux- [email protected]; [email protected]; [email protected]; Sonang Patel <[email protected]>; Ankit Agrawal <[email protected]>
Subject: [PATCH v1 7/8] iommu: Park TDISP T=0 devices in the blocking domain

A TDISP T=0 device stays associated with its guest T=1 vIOMMU, yet doesn't use that IOMMU for DMA translation. Instead, park its guest-visible stream in the driver's blocking domain.

Linux's model requires a device to either use T=0 or T=1. Aside from MSI, it cannot use T=0 for normal DMA once moved into T=1 mode, since the device will have IOVA's that are not valid in T=0.

Select the blocking domain before normal default-domain policy is applied.

Direct-map reserved regions are still fine, because the T=0 stream always goes to an identity mapping. Skip them here, as recording the request would only refuse the device its blocking domain.

Reject sysfs domain changes, driver-managed group attachment, and any PASID
attachments that would install a translating domain. The state is uniform across each group because all devices on a confidential IOMMU start in T=0.

Suggested-by Jason Gunthorpe <[email protected]>

Assisted-by Claude:claude-opus-5

Signed-off-by Nicolin Chen <[email protected]>

---
 drivers/iommu/iommu.c | 49
++++++++++++++++++++++++++++++++++++++++++-
 1 file changed, 48 insertions(+), 1 deletion(-)

drivers/iommu/iommu.c +3 -0

index 7ac6569af6773..d6b00e0373f5c 100644
@@ -1238,6 +1238,14 @@ static int
 iommu_create_device_direct_mappings(struct iommu_domain *domain,
 	unsigned long pg_size;
 	int ret = 0;
 
+	/*
+	 * The direct-map reserved regions are still fine because the T=0 stream
+	 * always goes to an identity mapping. Skip them: recording the

request

drivers/iommu/iommu.c +5 -0

+	 * would only refuse the device its blocking domain.
+	 */
+	if (iommu_using_t0_stream(dev))
+		return 0;
+
 	pg_size = domain->pgsize_bitmap ? 1UL << __ffs(domain-

Quoted 1 line

pgsize_bitmap) : 0;

drivers/iommu/iommu.c +4 -1

 	if (WARN_ON_ONCE(iommu_is_dma_domain(domain) && !pg_size))

@@ -1790,11 +1798,22 @@ __iommu_group_alloc_default_domain(struct
 iommu_group *group, int req_type)
 static struct iommu_domain *
 iommu_group_alloc_default_domain(struct iommu_group *group, int
 req_type)
 {
-	const struct iommu_ops *ops =
 dev_iommu_ops(iommu_group_first_dev(group));
+	struct device *first = iommu_group_first_dev(group);
+	const struct iommu_ops *ops = dev_iommu_ops(first);
 	struct iommu_domain *dom;
 
 	lockdep_assert_held(&group->mutex);
 
+	/*
+	 * When in T=0 mode the T=1 vIOMMU must always be set to

BLOCKED to

Quoted 5 lines

(quoted diff) +2 -0

+	/*
+	 * When in T=0 mode the T=1 vIOMMU must always be set to

BLOCKED to

drivers/iommu/iommu.c +2 -0

+	 * release control of ATS.
+	 */

drivers/iommu/iommu.c __iommu_group_alloc_default_domain(struct iommu_group *group, int req_type) · line 1814

Quoted 4 lines

drivers/iommu/iommu.c +4 -0

+	if (iommu_using_t0_stream(first)) {
+		if (!ops->blocked_domain)
+			return ERR_PTR(-EINVAL);
+		return ops->blocked_domain;

How is MSI allocation handled for T=0 devices? The ITS calls iommu_dma_prepare_msi(), which appears to return -EOPNOTSUPP for the blocked domain. Is that intentional?

Quoted 5 lines · Shameer Kolothum Thodi

Quoted 5 lines

(quoted diff) +2 -0

+	/*
+	 * When in T=0 mode the T=1 vIOMMU must always be set to

BLOCKED to

(quoted diff) +2 -0

+	 * release control of ATS.
+	 */

Quoted 8 lines

Review

Quoted 4 lines

(quoted diff) +4 -0

+	if (iommu_using_t0_stream(first)) {
+		if (!ops->blocked_domain)
+			return ERR_PTR(-EINVAL);
+		return ops->blocked_domain;

How is MSI allocation handled for T=0 devices? The ITS calls iommu_dma_prepare_msi(), which appears to return -EOPNOTSUPP for the blocked domain. Is that intentional?

For a TDISP capable devince MSI is always issued using T=0, meaning it does not go through the SMMU. It should be wired to defeat iommu_dma_prepare_msi() and use an identity IOVA as though there is no iommu present..

-----Original Message-----
From: Nicolin Chen <[email protected]>
Sent: 10 September 2026 04:33
To: Jason Gunthorpe <[email protected]>; Catalin Marinas <[email protected]>; Will Deacon <[email protected]>; [email protected]; Robin Murphy <[email protected]>; [email protected]; Danilo Krummrich <[email protected]>; Marek Szyprowski <[email protected]>; [email protected]
Cc: Mark Rutland <[email protected]>; Greg Kroah-Hartman <[email protected]>; Suzuki K Poulose <[email protected]>; Gavin Shan <[email protected]>; Vikram Sethi <[email protected]>; Anshuman Khandual <[email protected]>; Shanker Donthineni <[email protected]>; Mostafa Saleh <[email protected]>; [email protected]; Thomas Huth <[email protected]>; Marc Zyngier <[email protected]>; Ryan Roberts <[email protected]>; [email protected]; Kohei Enju <[email protected]>; Shaopeng Tan <[email protected]>; Ard Biesheuvel <[email protected]>; James Morse <[email protected]>; Steven Price <[email protected]>; Sang-Heon Jeon <[email protected]>; Omar Sandoval <[email protected]>; Andrew Morton <[email protected]>; Jinjie Ruan <[email protected]>; Sam Edwards <[email protected]>; Douglas Anderson <[email protected]>; Florian Fainelli <[email protected]>; Chen-Yu Tsai <[email protected]>; Huacai Chen <[email protected]>; Thomas Zimmermann <[email protected]>; Pranjal Shrivastava <[email protected]>; Ashish Mhetre <[email protected]>; Shameer Kolothum Thodi <[email protected]>; [email protected]; linux- [email protected]; [email protected]; [email protected]; Sonang Patel <[email protected]>; Ankit Agrawal <[email protected]>
Subject: [PATCH v1 8/8] iommu/arm-smmu-v3: Probe a guest-level Realm VSMMU via RSI commands

In CCA, the ACPI/etc doesn't tell the OS whether the SMMU is a confidential T=1 instance or a normal T=0 one. Instead, it has to be learned by issuing a trusted RSI. Before the kernel can operate the trusted T=1 IOMMU, it also has to validate all the information that it gets from ACPI against the true information that it gets from the RSI call, to ensure the ACPI is correct and prevent substitution attacks.

Use RSI_VSMMU_GET_INFO during probe and require the returned register range
to match firmware. Then use RSI_ARCH_DEV_ACTIVATE before mapping registers.

Currently the driver doesn't support a T=0 SMMU inside a realm. For example it doesn't make the page table allocations into shared memory. If we are in a realm reject any SMMU that is not T=1.

Once the SMMU is activated, its DMA will follow the DEV_FLAG_DMA_CC_PRIVATE
rules. It must set that flag to ensure its coherent allocations for its own structures are allocated from private memory, not the SWIOTLB shared pool.

Assisted-by Codex:gpt-5.6-sol

Signed-off-by Nicolin Chen <[email protected]>

---
 drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c | 55
+++++++++++++++++++++
 1 file changed, 55 insertions(+)

drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c +16 -0

index 5732f3ba0122d..972815c54b11f 100644
@@ -11,9 +11,11 @@
 
 #include <linux/acpi.h>
 #include <linux/acpi_iort.h>
+#include <linux/arm-rsi-cmds.h>
 #include <linux/bitops.h>
 #include <linux/crash_dump.h>
 #include <linux/delay.h>
+#include <linux/dma-mapping.h>
 #include <linux/err.h>
 #include <linux/interrupt.h>
 #include <linux/io-pgtable.h>

@@ -5507,6 +5509,53 @@ static struct arm_smmu_device
 *arm_smmu_impl_probe(struct arm_smmu_device *smmu)
 	return ERR_PTR(ret);
 }
 
+static void arm_smmu_clear_realm_private(void *dev)
+{
+	dma_set_cc_private(dev, false);
+}
+
+static int arm_smmu_probe_realm_vsmmu(struct arm_smmu_device
 *smmu,
+				      const struct resource *res)
+{
+	struct device *dev = smmu->dev;
+	unsigned long rsi_ret;
+	phys_addr_t top;
+
+	/*
+	 * Currently the driver does not support a T=0 SMMU inside a realm.

For

drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c +6 -0

+	 * instance it does not make the page table allocations into shared
+	 * memory. If we are in a realm reject any SMMU that is not T=1.
+	 */
+	rsi_ret = rsi_vsmmu_get_info(res->start, &top);
+	if (rsi_ret != RSI_SUCCESS) {
+		dev_err(dev, "RSI_VSMMU_GET_INFO failed for %pr: %lu\n",

res,

drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c +12 -0

+			rsi_ret);
+		return -ENODEV;
+	}
+
+	if (top != res->end + 1) {
+		dev_err(dev, "VSMMU range %pr ends at %pa\n", res, &top);
+		return -EINVAL;
+	}
+
+	rsi_ret = rsi_arch_dev_activate(res->start, RSI_ARCH_DEV_SMMUV3);
+	if (rsi_ret != RSI_SUCCESS) {
+		dev_err(dev, "RSI_ARCH_DEV_ACTIVATE failed for %pr:

%lu\n", res,

drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c +6 -0

+			rsi_ret);
+		return -EIO;
+	}
+
+	/*
+	 * Once activated, the SMMU DMA follows

DEV_FLAG_DMA_CC_PRIVATE so its

drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c +1 -0

+	 * queues and tables are allocated from private memory, not the

SWIOTLB

drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c +1 -0

+	 * shared pool. It only translates for a device we've requested the

RMM

drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c +5 -0

+	 * to put into T=1.
+	 */
+	iommu_device_set_confidential(&smmu->iommu, dev);
+
+	return devm_add_action_or_reset(dev,

arm_smmu_clear_realm_private, dev);

drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c +2 -0

+}
+
 static int arm_smmu_device_probe(struct platform_device *pdev)
 {
 	int irq, ret;

drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c static int arm_smmu_device_probe(struct · line 5599

Quoted 10 lines

drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c +5 -0

@@ -5542,6 +5591,12 @@ static int arm_smmu_device_probe(struct
 platform_device *pdev)
 	}
 	ioaddr = res->start;
 
+	if (is_realm_world()) {
+		ret = arm_smmu_probe_realm_vsmmu(smmu, res);
+		if (ret)
+			return ret;
+	}

If probe fails after activation succeeds above, wouldn't a module reload hit RSI_ERROR_DEVICE since the VSMMU is still ACTIVE?

B5.4.1.2:

pre: vsmmu.state == VSMMU_ACTIVE
post: result == RSI_ERROR_DEVICE

How is recovery handled?

-----Original Message-----
From: Nicolin Chen <[email protected]>
Sent: 28 October 2026 18:09
To: Shameer Kolothum Thodi <[email protected]>
Cc: Jason Gunthorpe <[email protected]>; Catalin Marinas <[email protected]>; Will Deacon <[email protected]>; [email protected]; Robin Murphy <[email protected]>; [email protected]; Danilo Krummrich <[email protected]>; Marek Szyprowski <[email protected]>; [email protected]; Mark Rutland <[email protected]>; Greg Kroah-Hartman <[email protected]>; Suzuki K Poulose <[email protected]>; Gavin Shan <[email protected]>; Vikram Sethi <[email protected]>; Anshuman Khandual <[email protected]>; Shanker Donthineni <[email protected]>; Mostafa Saleh <[email protected]>; [email protected]; Thomas Huth <[email protected]>; Marc Zyngier <[email protected]>; Ryan Roberts <[email protected]>; [email protected]; Kohei Enju <[email protected]>; Shaopeng Tan <[email protected]>; Ard Biesheuvel <[email protected]>; James Morse <[email protected]>; Steven Price <[email protected]>; Sang-Heon Jeon <[email protected]>; Omar Sandoval <[email protected]>; Andrew Morton <[email protected]>; Jinjie Ruan <[email protected]>; Sam Edwards <[email protected]>; Douglas Anderson <[email protected]>; Florian Fainelli <[email protected]>; Chen-Yu Tsai <[email protected]>; Huacai Chen <[email protected]>; Thomas Zimmermann <[email protected]>; Pranjal Shrivastava <[email protected]>; Ashish Mhetre <[email protected]>; [email protected]; linux- [email protected]; [email protected]; [email protected]; Sonang Patel <[email protected]>; Ankit Agrawal <[email protected]>
Subject: Re: [PATCH v1 8/8] iommu/arm-smmu-v3: Probe a guest-level Realm VSMMU via RSI commands

Quoted 16 lines · Shameer Kolothum Thodi

drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c static int arm_smmu_device_probe(struct · line 5599

Quoted 10 lines

drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c +5 -0

@@ -5542,6 +5591,12 @@ static int arm_smmu_device_probe(struct
 platform_device *pdev)
 	}
 	ioaddr = res->start;
 
+	if (is_realm_world()) {
+		ret = arm_smmu_probe_realm_vsmmu(smmu, res);
+		if (ret)
+			return ret;
+	}

If probe fails after activation succeeds above, wouldn't a module reload hit RSI_ERROR_DEVICE since the VSMMU is still ACTIVE?

B5.4.1.2:

Quoted 4 lines

pre: vsmmu.state == VSMMU_ACTIVE
post: result == RSI_ERROR_DEVICE

How is recovery handled?

There is no way to undo an activation. But what's the practical use case for the SMMU driver to do a module reload?