[PATCH 1/1] iommu/vt-d: Restore previous domain::aperture_end calculation

[PATCH 1/1] iommu/vt-d: Restore previous domain::aperture_end calculation

[Lu Baolu]

Commit d373449d8e97 ("iommu/vt-d: Use the generic iommu page table")
changed the calculation of domain::aperture_end. Previously, it was
calculated as:

    domain->domain.geometry.aperture_end =
            __DOMAIN_MAX_ADDR(domain->gaw - 1);

where domain->gaw was limited to less than MGAW.

Currently, it is calculated purely based on the max level of the page
table that the hardware supports. This is incorrect as stated in Section
3.6 of the VT-d spec:

  "Software using first-stage translation structures to translate an IO
   Virtual Address (IOVA) must use canonical addresses. Additionally,
   software must limit addresses to less than the minimum of MGAW and the
   lower canonical address width implied by FSPM (i.e., 47-bit when FSPM
   is 4-level and 56-bit when FSPM is 5-level)."

Restore the previous calculation method for domain::aperture_end to avoid
violating the spec. Incorrect aperture calculation causes GPU hangs
without generating VT-d faults on some Intel client platforms.

Fixes: d373449d8e97 ("iommu/vt-d: Use the generic iommu page table")
Reported-by: Chaitanya Kumar Borah <chaitanya.kumar.borah@intel.com>
Closes: https://lore.kernel.org/r/4f15cf3b-6fad-4cd8-87e5-6d86c0082673@intel.com
Suggested-by: Jason Gunthorpe <jgg@nvidia.com>
Suggested-by: Kevin Tian <kevin.tian@intel.com>
Signed-off-by: Lu Baolu <baolu.lu@linux.intel.com>
---
 drivers/iommu/intel/iommu.c | 10 ++++++++++
 1 file changed, 10 insertions(+)

diff --git a/drivers/iommu/intel/iommu.c b/drivers/iommu/intel/iommu.c
index 2d2f64ce2bc6..7b3016491ca5 100644
--- a/drivers/iommu/intel/iommu.c
+++ b/drivers/iommu/intel/iommu.c
@@ -2817,6 +2817,16 @@ intel_iommu_domain_alloc_first_stage(struct device *dev,
 		cfg.common.hw_max_vasz_lg2 = 57;
 	else
 		cfg.common.hw_max_vasz_lg2 = 48;
+
+	/*
+	 * Spec 3.6 First-Stage Translation:
+	 *
+	 * Software must limit addresses to less than the minimum of MGAW
+	 * and the lower canonical address width implied by FSPM (i.e.,
+	 * 47-bit when FSPM is 4-level and 56-bit when FSPM is 5-level).
+	 */
+	cfg.common.hw_max_vasz_lg2 = min(cap_mgaw(iommu->cap),
+					 cfg.common.hw_max_vasz_lg2);
 	cfg.common.hw_max_oasz_lg2 = 52;
 	cfg.common.features = BIT(PT_FEAT_SIGN_EXTEND) |
 			      BIT(PT_FEAT_FLUSH_RANGE);
-- 
2.43.0

Re: [PATCH 1/1] iommu/vt-d: Restore previous domain::aperture_end calculation

[Joerg Roedel]

On Thu, Nov 20, 2025 at 03:25:24PM +0800, Lu Baolu wrote:
> Fixes: d373449d8e97 ("iommu/vt-d: Use the generic iommu page table")
> Reported-by: Chaitanya Kumar Borah <chaitanya.kumar.borah@intel.com>
> Closes: https://lore.kernel.org/r/4f15cf3b-6fad-4cd8-87e5-6d86c0082673@intel.com
> Suggested-by: Jason Gunthorpe <jgg@nvidia.com>
> Suggested-by: Kevin Tian <kevin.tian@intel.com>
> Signed-off-by: Lu Baolu <baolu.lu@linux.intel.com>
> ---
>  drivers/iommu/intel/iommu.c | 10 ++++++++++
>  1 file changed, 10 insertions(+)

Applied, thanks.

Re: [PATCH 1/1] iommu/vt-d: Restore previous domain::aperture_end calculation

[Jason Gunthorpe]

On Thu, Nov 20, 2025 at 03:25:24PM +0800, Lu Baolu wrote:
> --- a/drivers/iommu/intel/iommu.c
> +++ b/drivers/iommu/intel/iommu.c
> @@ -2817,6 +2817,16 @@ intel_iommu_domain_alloc_first_stage(struct device *dev,
>  		cfg.common.hw_max_vasz_lg2 = 57;
>  	else
>  		cfg.common.hw_max_vasz_lg2 = 48;
> +
> +	/*
> +	 * Spec 3.6 First-Stage Translation:
> +	 *
> +	 * Software must limit addresses to less than the minimum of MGAW
> +	 * and the lower canonical address width implied by FSPM (i.e.,
> +	 * 47-bit when FSPM is 4-level and 56-bit when FSPM is 5-level).
> +	 */
> +	cfg.common.hw_max_vasz_lg2 = min(cap_mgaw(iommu->cap),
> +					 cfg.common.hw_max_vasz_lg2);
>  	cfg.common.hw_max_oasz_lg2 = 52;
>  	cfg.common.features = BIT(PT_FEAT_SIGN_EXTEND) |
>  			      BIT(PT_FEAT_FLUSH_RANGE);

This is missing the hunk for paging_domain_compatible_first_stage(), I
think that is important!

Jason

Re: [PATCH 1/1] iommu/vt-d: Restore previous domain::aperture_end calculation

[Baolu Lu]

On 11/20/25 21:00, Jason Gunthorpe wrote:
> On Thu, Nov 20, 2025 at 03:25:24PM +0800, Lu Baolu wrote:
>> --- a/drivers/iommu/intel/iommu.c
>> +++ b/drivers/iommu/intel/iommu.c
>> @@ -2817,6 +2817,16 @@ intel_iommu_domain_alloc_first_stage(struct device *dev,
>>   		cfg.common.hw_max_vasz_lg2 = 57;
>>   	else
>>   		cfg.common.hw_max_vasz_lg2 = 48;
>> +
>> +	/*
>> +	 * Spec 3.6 First-Stage Translation:
>> +	 *
>> +	 * Software must limit addresses to less than the minimum of MGAW
>> +	 * and the lower canonical address width implied by FSPM (i.e.,
>> +	 * 47-bit when FSPM is 4-level and 56-bit when FSPM is 5-level).
>> +	 */
>> +	cfg.common.hw_max_vasz_lg2 = min(cap_mgaw(iommu->cap),
>> +					 cfg.common.hw_max_vasz_lg2);
>>   	cfg.common.hw_max_oasz_lg2 = 52;
>>   	cfg.common.features = BIT(PT_FEAT_SIGN_EXTEND) |
>>   			      BIT(PT_FEAT_FLUSH_RANGE);
> This is missing the hunk for paging_domain_compatible_first_stage(), I
> think that is important!

Yes. I want to make that a separate patch as that will be Cc'd to stable
and backported further than this one. We should have such a
compatibility check even without the generic iopt conversion, right?

Thanks,
baolu

RE: [PATCH 1/1] iommu/vt-d: Restore previous domain::aperture_end calculation

[Tian, Kevin]

> From: Baolu Lu <baolu.lu@linux.intel.com>
> Sent: Friday, November 21, 2025 9:40 AM
> 
> On 11/20/25 21:00, Jason Gunthorpe wrote:
> > On Thu, Nov 20, 2025 at 03:25:24PM +0800, Lu Baolu wrote:
> >> --- a/drivers/iommu/intel/iommu.c
> >> +++ b/drivers/iommu/intel/iommu.c
> >> @@ -2817,6 +2817,16 @@ intel_iommu_domain_alloc_first_stage(struct
> device *dev,
> >>   		cfg.common.hw_max_vasz_lg2 = 57;
> >>   	else
> >>   		cfg.common.hw_max_vasz_lg2 = 48;
> >> +
> >> +	/*
> >> +	 * Spec 3.6 First-Stage Translation:
> >> +	 *
> >> +	 * Software must limit addresses to less than the minimum of MGAW
> >> +	 * and the lower canonical address width implied by FSPM (i.e.,
> >> +	 * 47-bit when FSPM is 4-level and 56-bit when FSPM is 5-level).
> >> +	 */
> >> +	cfg.common.hw_max_vasz_lg2 = min(cap_mgaw(iommu->cap),
> >> +					 cfg.common.hw_max_vasz_lg2);
> >>   	cfg.common.hw_max_oasz_lg2 = 52;
> >>   	cfg.common.features = BIT(PT_FEAT_SIGN_EXTEND) |
> >>   			      BIT(PT_FEAT_FLUSH_RANGE);
> > This is missing the hunk for paging_domain_compatible_first_stage(), I
> > think that is important!
> 
> Yes. I want to make that a separate patch as that will be Cc'd to stable
> and backported further than this one. We should have such a
> compatibility check even without the generic iopt conversion, right?
> 

No, I don't think we should backport a change which might break the
old usage.

Instead the main reason here is to unblock the vt-d generic_pt support
in this cycle. For that purpose it's better to match the old behavior (which
doesn't have this check) to avoid regression. Then we work on a 
follow-up patch to enforce the compatibility check which can be easily
improved/reverted based on what might be (unexpectedly) broken.