linux-kernel - Re: [PATCH] iommu/amd: Add support for hw

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: <20250825134420.GB1970008@nvidia.com>
Date: Mon, 25 Aug 2025 10:44:20 -0300
From: Jason Gunthorpe <jgg@...dia.com>
To: Suravee Suthikulpanit <suravee.suthikulpanit@....com>
Cc: linux-kernel@...r.kernel.org, joro@...tes.org, kevin.tian@...el.com,
	vasant.hegde@....com, iommu@...ts.linux.dev, santosh.shukla@....com,
	sairaj.arunkodilkar@....com, jon.grimm@....com,
	prashanthpra@...gle.com, wvw@...gle.com, wnliu@...gle.com,
	gptran@...gle.com, kpsingh@...gle.com
Subject: Re: [PATCH] iommu/amd: Add support for hw_info for iommu capability
 query

On Wed, Aug 20, 2025 at 04:25:33AM +0000, Suravee Suthikulpanit wrote:
> AMD IOMMU Extended Feature (EFR) and Extended Feature 2 (EFR2) registers
> specify features supported by each IOMMU hardware instance.
> The IOMMU driver checks each feature-specific bits before enabling
> each feature at run time.
> 
> For IOMMUFD, the hypervisor determines which IOMMU features to support
> in the guest, and communicates this information to user-space (e.g. QEMU)
> via iommufd IOMMU_DEVICE_GET_HW_INFO ioctl.
> 
> Signed-off-by: Suravee Suthikulpanit <suravee.suthikulpanit@....com>
> ---
>  drivers/iommu/amd/amd_iommu_types.h |  3 +++
>  drivers/iommu/amd/iommu.c           | 40 +++++++++++++++++++++++++++++
>  include/uapi/linux/iommufd.h        | 19 ++++++++++++++
>  3 files changed, 62 insertions(+)

Can you follow what ARM did and put the iommufd functions in a
amd/iommufd.c file? I think that worked pretty good.

Jason

> diff --git a/drivers/iommu/amd/amd_iommu_types.h b/drivers/iommu/amd/amd_iommu_types.h
> index 5219d7ddfdaa..efdd0cbda1df 100644
> --- a/drivers/iommu/amd/amd_iommu_types.h
> +++ b/drivers/iommu/amd/amd_iommu_types.h
> @@ -95,9 +95,12 @@
>  #define FEATURE_HE		BIT_ULL(8)
>  #define FEATURE_PC		BIT_ULL(9)
>  #define FEATURE_HATS		GENMASK_ULL(11, 10)
> +#define FEATURE_GATS_SHIFT	12
>  #define FEATURE_GATS		GENMASK_ULL(13, 12)
> +#define FEATURE_GLX_SHIFT	14
>  #define FEATURE_GLX		GENMASK_ULL(15, 14)
>  #define FEATURE_GAM_VAPIC	BIT_ULL(21)
> +#define FEATURE_PASMAX_SHIFT	32
>  #define FEATURE_PASMAX		GENMASK_ULL(36, 32)

Please no.. FIELD_PREP is how to get the shift, don't add constants.

> diff --git a/drivers/iommu/amd/iommu.c b/drivers/iommu/amd/iommu.c
> index eb348c63a8d0..ebe1cb9b0807 100644
> --- a/drivers/iommu/amd/iommu.c
> +++ b/drivers/iommu/amd/iommu.c
> @@ -3038,8 +3038,48 @@ static const struct iommu_dirty_ops amd_dirty_ops = {
>  	.read_and_clear_dirty = amd_iommu_read_and_clear_dirty,
>  };
>  
> +#define AMD_VIOMMU_EFR_GUEST_TRANSLATION_FLAGS \
> +	(FEATURE_GT | FEATURE_GA | FEATURE_GIOSUP | \
> +	 FEATURE_PPR | FEATURE_EPHSUP)
> +
> +static void _build_efr_guest_translation(struct amd_iommu *iommu, u64 *efr, u64 *efr2)
> +{
> +	/*
> +	 * Build the EFR against the current hardware capabilities
> +	 *
> +	 * Also, not all IOMMU features are emulated by KVM.
> +	 * Therefore, only advertise what KVM can support
> +	 * or virtualzied by the hardware.
> +	 */

What does KVM have to do with iommu features on AMD architecture??

> +	if (!efr)
> +		return;
> +
> +	*efr |= (amd_iommu_efr & AMD_VIOMMU_EFR_GUEST_TRANSLATION_FLAGS);
> +	*efr |= (FIELD_GET(FEATURE_GATS, amd_iommu_efr) << FEATURE_GATS_SHIFT);
> +	*efr |= (FIELD_GET(FEATURE_GLX, amd_iommu_efr) << FEATURE_GLX_SHIFT);
> +	*efr |= (FIELD_GET(FEATURE_PASMAX, amd_iommu_efr) << FEATURE_PASMAX_SHIFT);
> +	pr_debug("%s: efr=%#llx\n", __func__, *efr);
> +}

I'm not sure all this masking is a good idea, how do you intend to
handshake upgrades when more features are supported if masking is
present?

Nothing sets efr2?

> +/**
> + * struct iommu_hw_info_amd - AMD IOMMU device info
> + *
> + * @efr : Value of AMD IOMMU Extended Feature Register (EFR)
> + * @efr2: Value of AMD IOMMU Extended Feature 2 Register (EFR2)
> + *
> + * Please See description of these registers in the following sections of
> + * the AMD I/O Virtualization Technology (IOMMU) Specification.
> + * (https://www.amd.com/content/dam/amd/en/documents/processor-tech-docs/specifications/48882_IOMMU.pdf)
> + *
> + * - MMIO Offset 0030h IOMMU Extended Feature Register
> + * - MMIO Offset 01A0h IOMMU Extended Feature 2 Register
> + */

Need to document the masking and explain what the forwards/backwards
compatible strategy is here.

I think you should probably just pass the raw HW value through and
require the VMM to figure out what bits it needs based on feature
flags elsewhere.

Jason