Re: [PATCH 5/5] iommu/vt-d: Reserve MSB of domain ID space for TDX module

[Baolu Lu <baolu.lu@linux.intel.com>]

On 9/15/2026 4:11 PM, sashiko-bot@kernel.org wrote:
> Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
> - [High] iommu: missing TDX teardown and mt_pages leak on IOMMU hot-remove
> --
> 
> commit 8a16aba70396ddc74c834953ff8123fae8be9bad
> Author: Lu Baolu <baolu.lu@linux.intel.com>
> 
> iommu/vt-d: Reserve MSB of domain ID space for TDX module
> 
> When an Intel IOMMU is enabled for TDX Connect, the VT-d DID namespace
> must be split so the TDX module can use the MSB-tagged half for trusted
> DMA translations, while the host/VMM uses the lower half.
> 
>> diff --git a/drivers/iommu/intel/tdxc.c b/drivers/iommu/intel/tdxc.c
>> index b5dfdeeb23dba..1ca03257d4563 100644
>> --- a/drivers/iommu/intel/tdxc.c
>> +++ b/drivers/iommu/intel/tdxc.c
> [ ... ]
>> @@ -154,17 +159,27 @@ static int intel_iommu_bringup_tdxc(struct intel_iommu *iommu, unsigned int nr_p
>>   		return -EFAULT;
>>   	}
>>   
>> +	/*
>> +	 * Intel TDX Connect Architecture Specification, Section 2.2 Trusted DMA
>> +	 *
>> +	 * When IOMMU is enabled to support TDX Connect, the IOMMU restricts
>> +	 * the VMM’s DID setting, reserving the MSB bit for the TDX module. The
>> +	 * TDX module always sets this reserved bit on the trusted DMA table.
>> +	 */
>> +	iommu->max_domain_id = ndoms >> 1;
>>   	iommu->tdx_iommu_id = tdx_iommu_id;
>>   	iommu->mt_pages = no_free_ptr(iommu_mt);
>>   
>> -	/* Bring-up is not complete yet; report as unsupported for now. */
>> -	return -EOPNOTSUPP;
>> +	pr_info("%s: trusted DMA for TEE/IO initialized\n", iommu->name);
>> +
>> +	return 0;
> 
> [Severity: High]
> With TDX bring-up now successfully completing here, if this IOMMU is later
> hot-removed, does this leak the TDX metadata pages (iommu->mt_pages) and leave
> dangling hardware state in the SEAM firmware?

This path is basically unreachable in practice. No TDX Connect-capable
platform supports DMAR hotplug.

> 
> When ACPI hotplug invokes dmar_iommu_hotplug() with insert=false, the IOMMU
> is destroyed via:
> 
> drivers/iommu/intel/iommu.c:dmar_iommu_hotplug() {
>      ...
> 		disable_dmar_iommu(iommu);
> 		free_dmar_iommu(iommu);
>      ...
> }

I will add the following check for future proofing:

diff --git a/drivers/iommu/intel/iommu.c b/drivers/iommu/intel/iommu.c
index e88457d96b53..16203604b751 100644
--- a/drivers/iommu/intel/iommu.c
+++ b/drivers/iommu/intel/iommu.c
@@ -2202,6 +2202,10 @@ int dmar_iommu_hotplug(struct dmar_drhd_unit 
*dmaru, bool insert)
         if (insert) {
                 ret = intel_iommu_add(dmaru);
         } else {
+#ifdef CONFIG_INTEL_IOMMU_TDX_CONNECT
+               if (iommu->mt_pages)
+                       return -EBUSY;
+#endif
                 disable_dmar_iommu(iommu);
                 free_dmar_iommu(iommu);
         }

> 
> Because this hot-remove path never calls intel_iommu_teardown_tdxc(), it
> appears iommu->mt_pages is leaked and tdh_iommu_clear() is never called before
> the IOMMU structure itself is freed.
> 

Thanks,
baolu