RE: [PATCH v1 7/8] iommu: Park TDISP T=0 devices in the blocking domain

[Shameer Kolothum Thodi]

> -----Original Message-----
> From: Nicolin Chen <nicolinc@xxxxxxxxxx>
> Sent: 10 September 2026 04:33
> To: Jason Gunthorpe <jgg@xxxxxxxxxx>; Catalin Marinas
> <catalin.marinas@xxxxxxx>; Will Deacon <will@xxxxxxxxxx>;
> joro@xxxxxxxxxx; Robin Murphy <robin.murphy@xxxxxxx>;
> rafael@xxxxxxxxxx; Danilo Krummrich <dakr@xxxxxxxxxx>; Marek Szyprowski
> <m.szyprowski@xxxxxxxxxxx>; aneesh.kumar@xxxxxxxxxx
> Cc: Mark Rutland <mark.rutland@xxxxxxx>; Greg Kroah-Hartman
> <gregkh@xxxxxxxxxxxxxxxxxxx>; Suzuki K Poulose
> <suzuki.poulose@xxxxxxx>; Gavin Shan <gshan@xxxxxxxxxx>; Vikram Sethi
> <vsethi@xxxxxxxxxx>; Anshuman Khandual
> <anshuman.khandual@xxxxxxx>; Shanker Donthineni
> <sdonthineni@xxxxxxxxxx>; Mostafa Saleh <smostafa@xxxxxxxxxx>;
> rppt@xxxxxxxxxx; Thomas Huth <thuth@xxxxxxxxxx>; Marc Zyngier
> <maz@xxxxxxxxxx>; Ryan Roberts <ryan.roberts@xxxxxxx>; kas@xxxxxxxxxx;
> Kohei Enju <enju.kohei@xxxxxxxxxxx>; Shaopeng Tan
> <tan.shaopeng@xxxxxxxxxxxxxx>; Ard Biesheuvel <ardb@xxxxxxxxxx>; James
> Morse <james.morse@xxxxxxx>; Steven Price <steven.price@xxxxxxx>;
> Sang-Heon Jeon <ekffu200098@xxxxxxxxx>; Omar Sandoval
> <osandov@xxxxxx>; Andrew Morton <akpm@xxxxxxxxxxxxxxxxxxxx>; Jinjie
> Ruan <ruanjinjie@xxxxxxxxxx>; Sam Edwards <cfsworks@xxxxxxxxx>;
> Douglas Anderson <dianders@xxxxxxxxxxxx>; Florian Fainelli
> <florian.fainelli@xxxxxxxxxxxx>; Chen-Yu Tsai <wenst@xxxxxxxxxxxx>;
> Huacai Chen <chenhuacai@xxxxxxxxxx>; Thomas Zimmermann
> <tzimmermann@xxxxxxx>; Pranjal Shrivastava <praan@xxxxxxxxxx>; Ashish
> Mhetre <amhetre@xxxxxxxxxx>; Shameer Kolothum Thodi
> <skolothumtho@xxxxxxxxxx>; linux-arm-kernel@xxxxxxxxxxxxxxxxxxx; linux-
> kernel@xxxxxxxxxxxxxxx; iommu@xxxxxxxxxxxxxxx; driver-core@xxxxxxxxxxxxxxx;
> Sonang Patel <sonangp@xxxxxxxxxx>; Ankit Agrawal <ankita@xxxxxxxxxx>
> 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 <jgg@xxxxxxxxxx>
> Assisted-by: Claude:claude-opus-5
> Signed-off-by: Nicolin Chen <nicolinc@xxxxxxxxxx>
> ---
>  drivers/iommu/iommu.c | 49
> ++++++++++++++++++++++++++++++++++++++++++-
>  1 file changed, 48 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/iommu/iommu.c b/drivers/iommu/iommu.c
> index 7ac6569af6773..d6b00e0373f5c 100644
> --- a/drivers/iommu/iommu.c
> +++ b/drivers/iommu/iommu.c
> @@ -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
> +	 * would only refuse the device its blocking domain.
> +	 */
> +	if (iommu_using_t0_stream(dev))
> +		return 0;
> +
>  	pg_size = domain->pgsize_bitmap ? 1UL << __ffs(domain-
> >pgsize_bitmap) : 0;
> 
>  	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
> +	 * release control of ATS.
> +	 */
> +	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?

Thanks,
Shameer