Re: [PATCH rc] iommu/amd: Fix geometry.aperture_end for V2 tables

[Vasant Hegde <vasant.hegde@amd.com>]

Jason,


On 5/28/2025 5:27 PM, Jason Gunthorpe wrote:
> On Wed, May 28, 2025 at 02:17:56PM +0530, Vasant Hegde wrote:
>>> Yes, it should use bit 56 for address translation, that is part of the
>>> page table architecture.
>>
>> I have checked with HW architects.
>>
>> In DMA API mode (PASID=0), IOMMU HW does not use canonical
>> addresses. 
> 
> Do you really mean PASID=0 but still using a AMDv2 table with the
> GCR3? That seems wild that only PASID0 would break the normal rules
> for x86 page tables...

Right . AMD V2 (guest page table) with PASID zero (DMA API Mode).

> 
> We already know AMDv1 is different and that is documented, and it only
> works on PASID0.
> 
>> It's safe to use bit 56 (5 level page table) -OR- bit 47 (4 level
>> page table) for address translation (we don't need sign
>> extension). 
> 
> But does it validate that the upper bits are zero or does it ignore
> them? As I mentioned previously ignoring them breaks ATS.

I believe HW will validate and handle ATS requests properly.

> 
>> However when PASID is *enabled* (PASID != 0), then IOMMU
>> expects canonical address bit[63-57] should match bit[56]. Otherwise
>> it will abort the request.
> 
> Okay that's great at least.
> 
> But this is a pain.. Since iommu_domains don't act differently
> depending on what PASID they are linked to we have to use the least
> common denominator, meaning we should disable use of the top bit
> entirely, and disable use of sign extension.

That should be fine. We can limit to `page level - 1` bits.

> 
>> I have requested spec writer to add details in the spec.
> 
> Yes please, this special behavior for PASID0 is very shocking.

yep!

-Vasant