[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <BN9PR11MB52766996DFF5A14C6EB560F98CD5A@BN9PR11MB5276.namprd11.prod.outlook.com>
Date: Fri, 21 Nov 2025 07:30:34 +0000
From: "Tian, Kevin" <kevin.tian@...el.com>
To: Baolu Lu <baolu.lu@...ux.intel.com>, Jason Gunthorpe <jgg@...dia.com>
CC: Joerg Roedel <joro@...tes.org>, Will Deacon <will@...nel.org>, "Robin
Murphy" <robin.murphy@....com>, "Borah, Chaitanya Kumar"
<chaitanya.kumar.borah@...el.com>, "iommu@...ts.linux.dev"
<iommu@...ts.linux.dev>, "linux-kernel@...r.kernel.org"
<linux-kernel@...r.kernel.org>
Subject: RE: [PATCH 1/1] iommu/vt-d: Restore previous domain::aperture_end
calculation
> From: Baolu Lu <baolu.lu@...ux.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.
Powered by blists - more mailing lists