Re: [PATCH v5 0/4] Respect VASIZE for address limits
From: Ankit Soni
Date: Fri May 15 2026 - 00:48:39 EST
On Fri, May 08, 2026 at 12:23:00PM -0700, Jerry Snitselaar wrote:
> On Mon, Apr 13, 2026 at 02:45:17PM +0000, Ankit Soni wrote:
> > The AMD IOMMU driver was only using EFR[HATS] to derive the VA size,
> > ignoring the IVINFO[VASIZE] limit. This could create domains that
> > exceed the bounds advertised by hypervisor. With this series, driver
> > respects IVINFO[VASIZE] when determining the addressable VA range.
> >
>
> Should the AMD code also respect IVINFO[PASIZE]? VMWare presents an IVRS
> table that has both set to 40 bits.
>
> [000h 0000 004h] Signature : "IVRS" [I/O Virtualization Reporting Structure]
> [004h 0004 004h] Table Length : 000000BC
> [008h 0008 001h] Revision : 01
> [009h 0009 001h] Checksum : AD
> [00Ah 0010 006h] Oem ID : "VMWARE"
> [010h 0016 008h] Oem Table ID : "VMW IVRS"
> [018h 0024 004h] Oem Revision : 06040001
> [01Ch 0028 004h] Asl Compiler ID : "VMW "
> [020h 0032 004h] Asl Compiler Revision : 00000001
>
> [024h 0036 004h] Virtualization Info : 00142803
> [028h 0040 008h] Reserved : 0000000000000000
>
> [030h 0048 001h] Subtable Type : 11 [Hardware Definition Block (IVHD)]
> [031h 0049 001h] Flags (decoded below) : 00
> HtTunEn : 0
> PassPW : 0
> ResPassPW : 0
> Isoc Control : 0
> Iotlb Support : 0
> Coherent : 0
> Prefetch Support : 0
> PPR Support : 0
> [032h 0050 002h] Length : 008C
> [034h 0052 002h] DeviceId : 0010
> [036h 0054 002h] Capability Offset : 0040
> [038h 0056 008h] Base Address : 00000000FEC10000
> [040h 0064 002h] PCI Segment Group : 0000
> [042h 0066 002h] Virtualization Info : 0000
> [044h 0068 004h] Attributes : 00000000
> [048h 0072 008h] EFR Image : 00004000000000C4
> [050h 0080 008h] Reserved : 0000000000000000
>
> Regards,
> Jerry
>
Hi Jerry,
Good point regarding also considering PASize.
Currently, with this patch we only limit the VA size based on the
IVHD-reported capability because that directly reflects what the IOMMU can
support for virtual address translation. For physical addresses, we are
effectively allowing up to 52 bits unconditionally, which matches the
current hardcoded assumption and effectively does not constrain the mm
layer.
Your suggestion to additionally restrict PASize makes sense from a
correctness perspective. If we propagate the IOMMU-reported physical
address size, we could detect cases where the mm layer provides addresses
that exceed what the IOMMU hardware can actually handle. In such scenarios,
it would clearly indicate a mismatch/bug somewhere in the stack (either
incorrect capability reporting or misuse by the mm layer).
I will add enforce on pasize change and send a patch.
Thanks,
Ankit
> > For a small VA size, domain initialization in the generic page table
> > framework can fail with -EOPNOTSUPP. This happens because the page table
> > clears the dynamic top feature from the force enabled feature set, as no
> > page table growth is needed beyond the current level.
> > This series also fixes this issue and adds KUnit test coverage for the
> > 32-bit VA configuration.
> >
> > Changes:
> > v5: - Added Jason's suggestion for modifying get_info().
> > v4: - Remove PT_FEAT_DYNAMIC_TOP check from pt_init_common().
> > - Add test coverage in amdv1 for 32bit va size.
> > v3: - Remove specific value checking for vasize.
> > - Add patch for PT_FORCE_ENABLED_FEATURES.
> > v2: - Mark ivinfo_vasize_bits() as __init.
> >
> > Ankit Soni (4):
> > iommu_pt: Fix pgsize_bitmap calculation in get_info for smaller vasz's
> > iommu_pt: support small VA for AMDv1
> > iommu_pt: add kunit config for 32-bit VA (amdv1_cfg_1)
> > iommu/amd: Adhere to IVINFO[VASIZE] for address limits
> >
> > drivers/iommu/amd/amd_iommu.h | 2 +-
> > drivers/iommu/amd/amd_iommu_types.h | 1 +
> > drivers/iommu/amd/init.c | 13 +++++++++----
> > drivers/iommu/amd/iommu.c | 3 +--
> > drivers/iommu/generic_pt/fmt/amdv1.h | 1 +
> > drivers/iommu/generic_pt/iommu_pt.h | 12 ++++++------
> > drivers/iommu/generic_pt/kunit_generic_pt.h | 10 +++++++---
> > drivers/iommu/generic_pt/kunit_iommu_pt.h | 5 +++--
> > 8 files changed, 29 insertions(+), 18 deletions(-)
> >
> > --
> > 2.43.0
> >
>