[PATCH v1 8/8] iommu/arm-smmu-v3: Probe a guest-level Realm VSMMU via RSI commands

[Shameer Kolothum Thodi]

> -----Original Message-----
> From: Nicolin Chen <nicolinc at nvidia.com>
> Sent: 10 September 2026 04:33
> To: Jason Gunthorpe <jgg at nvidia.com>; Catalin Marinas
> <catalin.marinas at arm.com>; Will Deacon <will at kernel.org>;
> joro at 8bytes.org; Robin Murphy <robin.murphy at arm.com>;
> rafael at kernel.org; Danilo Krummrich <dakr at kernel.org>; Marek Szyprowski
> <m.szyprowski at samsung.com>; aneesh.kumar at kernel.org
> Cc: Mark Rutland <mark.rutland at arm.com>; Greg Kroah-Hartman
> <gregkh at linuxfoundation.org>; Suzuki K Poulose
> <suzuki.poulose at arm.com>; Gavin Shan <gshan at redhat.com>; Vikram Sethi
> <vsethi at nvidia.com>; Anshuman Khandual
> <anshuman.khandual at arm.com>; Shanker Donthineni
> <sdonthineni at nvidia.com>; Mostafa Saleh <smostafa at google.com>;
> rppt at kernel.org; Thomas Huth <thuth at redhat.com>; Marc Zyngier
> <maz at kernel.org>; Ryan Roberts <ryan.roberts at arm.com>; kas at kernel.org;
> Kohei Enju <enju.kohei at fujitsu.com>; Shaopeng Tan
> <tan.shaopeng at jp.fujitsu.com>; Ard Biesheuvel <ardb at kernel.org>; James
> Morse <james.morse at arm.com>; Steven Price <steven.price at arm.com>;
> Sang-Heon Jeon <ekffu200098 at gmail.com>; Omar Sandoval
> <osandov at fb.com>; Andrew Morton <akpm at linux-foundation.org>; Jinjie
> Ruan <ruanjinjie at huawei.com>; Sam Edwards <cfsworks at gmail.com>;
> Douglas Anderson <dianders at chromium.org>; Florian Fainelli
> <florian.fainelli at broadcom.com>; Chen-Yu Tsai <wenst at chromium.org>;
> Huacai Chen <chenhuacai at kernel.org>; Thomas Zimmermann
> <tzimmermann at suse.de>; Pranjal Shrivastava <praan at google.com>; Ashish
> Mhetre <amhetre at nvidia.com>; Shameer Kolothum Thodi
> <skolothumtho at nvidia.com>; linux-arm-kernel at lists.infradead.org; linux-
> kernel at vger.kernel.org; iommu at lists.linux.dev; driver-core at lists.linux.dev;
> Sonang Patel <sonangp at nvidia.com>; Ankit Agrawal <ankita at nvidia.com>
> 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 <nicolinc at nvidia.com>
> ---
>  drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c | 55
> +++++++++++++++++++++
>  1 file changed, 55 insertions(+)
> 
> diff --git a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c
> b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c
> index 5732f3ba0122d..972815c54b11f 100644
> --- a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c
> +++ b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c
> @@ -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
> +	 * 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,
> +			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,
> +			rsi_ret);
> +		return -EIO;
> +	}
> +
> +	/*
> +	 * Once activated, the SMMU DMA follows
> DEV_FLAG_DMA_CC_PRIVATE so its
> +	 * queues and tables are allocated from private memory, not the
> SWIOTLB
> +	 * shared pool. It only translates for a device we've requested the
> RMM
> +	 * 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);
> +}
> +
>  static int arm_smmu_device_probe(struct platform_device *pdev)
>  {
>  	int irq, ret;
> @@ -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?

Thanks,
Shameer