Re: [PATCH] iommu/amd: Adhere to IVINFO[VASIZE] for address limits

[Ankit Soni]

Hi,

On Mon, Mar 02, 2026 at 07:57:15PM -0400, Jason Gunthorpe wrote:
> On Fri, Feb 27, 2026 at 04:58:04PM +0000, Ankit Soni wrote:
> > +static u8 ivinfo_vasize_bits(void)
> > +{
> > +	u8 vasize;
> > +
> > +	vasize = FIELD_GET(IOMMU_IVINFO_VASIZE, amd_iommu_ivinfo);
> > +
> > +	/*
> > +	 * IVINFO[VASIZE] encodes the log2 of the maximum virtual address
> > +	 * processed by the IOMMU.
> > +	 */
> > +	switch (vasize) {
> > +	case 32:
> > +	case 40:
> > +	case 48:
> > +	case 64:
> > +		return vasize;
> > +	default:
> > +		pr_warn_once("IVRS: IVINFO[VASIZE]=0x%x is invalid, defaulting to 64‑bit VA\n",
> > +			     vasize);
> > +		return 64;
> 
> Why check and limit it like this? 
> 

I’ll replace this with a macro and send that in v3. If you have other suggestions,
I’m happy to incorporate.

> > -	cfg.common.hw_max_vasz_lg2 =
> > -		min(64, (amd_iommu_hpt_level - 1) * 9 + 21);
> > +	cfg.common.hw_max_vasz_lg2 = amd_iommu_hpt_vasize;
> 
> This has no restriction, you can send it whatever size you want.
> 

The intent is for the kernel to respect what the VM advertises in IVINFO.
If we ignore IVINFO[VASIZE] and use a larger limit (i.e. from EFR only),
driver can exceed vasize what the VM allows and break the guest.

> Shouldn't the v2 side respect this too? If there is some reason why
> not it would be good to include it in a comment.
> 
> Jason

For the v2 page table, GVASize is derived from the page table level already
advertised in EFR, so it matches what is reported and driver don’t need an
extra IVINFO-based check for v2.
For the v1 path, the effective VASize can differ from what EFR implies
(i.e. VM can report a smaller limit), so driver should respect IVINFO[VASIZE].

I’ll add a short comment in the code explaining this so the v2 behaviour is clear.

Thanks,
Ankit