[PATCH v1 7/8] iommu: Park TDISP T=0 devices in the blocking domain
Shameer Kolothum Thodi
skolothumtho at nvidia.com
Wed Oct 28 07:19:17 PDT 2026
> -----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 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 at nvidia.com>
> Assisted-by: Claude:claude-opus-5
> Signed-off-by: Nicolin Chen <nicolinc at nvidia.com>
> ---
> 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
More information about the linux-arm-kernel
mailing list