linux-kernel - Re: [PATCH 1/1] iommu/vt-d: Restore previous domain::aperture

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <e5376ae5-20f8-4e49-a912-7412361c66fd@linux.intel.com>
Date: Fri, 21 Nov 2025 09:39:57 +0800
From: Baolu Lu <baolu.lu@...ux.intel.com>
To: Jason Gunthorpe <jgg@...dia.com>
Cc: Joerg Roedel <joro@...tes.org>, Will Deacon <will@...nel.org>,
 Robin Murphy <robin.murphy@....com>, Kevin Tian <kevin.tian@...el.com>,
 Chaitanya Kumar Borah <chaitanya.kumar.borah@...el.com>,
 iommu@...ts.linux.dev, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 1/1] iommu/vt-d: Restore previous domain::aperture_end
 calculation

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