Re: [PATCH v5 0/4] Respect VASIZE for address limits

Re: [PATCH v5 0/4] Respect VASIZE for address limits

[Jerry Snitselaar]

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

> 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
>