public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Jason Gunthorpe <jgg@nvidia.com>
To: Suravee Suthikulpanit <suravee.suthikulpanit@amd.com>
Cc: linux-kernel@vger.kernel.org, iommu@lists.linux.dev,
	joro@8bytes.org, yi.l.liu@intel.com, kevin.tian@intel.com,
	nicolinc@nvidia.com, eric.auger@redhat.com, vasant.hegde@amd.com,
	jon.grimm@amd.com, santosh.shukla@amd.com, Dhaval.Giani@amd.com,
	pandoh@google.com, loganodell@google.com
Subject: Re: [RFC PATCH 2/6] iommu/amd: Add support for hw_info for iommu capability query
Date: Wed, 13 Dec 2023 09:27:21 -0400	[thread overview]
Message-ID: <20231213132721.GT3014157@nvidia.com> (raw)
In-Reply-To: <20231212160139.174229-3-suravee.suthikulpanit@amd.com>

On Tue, Dec 12, 2023 at 10:01:35AM -0600, 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@amd.com>
> ---
>  drivers/iommu/amd/amd_iommu.h       |  2 ++
>  drivers/iommu/amd/amd_iommu_types.h |  3 +++
>  drivers/iommu/amd/iommu.c           | 38 +++++++++++++++++++++++++++++
>  include/uapi/linux/iommufd.h        | 13 ++++++++++
>  4 files changed, 56 insertions(+)
> 
> diff --git a/drivers/iommu/amd/amd_iommu.h b/drivers/iommu/amd/amd_iommu.h
> index 108253edbeb0..4118129f4a24 100644
> --- a/drivers/iommu/amd/amd_iommu.h
> +++ b/drivers/iommu/amd/amd_iommu.h
> @@ -72,6 +72,8 @@ void amd_iommu_dev_flush_pasid_pages(struct iommu_dev_data *dev_data,
>  void amd_iommu_dev_flush_pasid_all(struct iommu_dev_data *dev_data,
>  				   ioasid_t pasid);
>  
> +void amd_iommu_build_efr(u64 *efr, u64 *efr2);
> +
>  #ifdef CONFIG_IRQ_REMAP
>  int amd_iommu_create_irq_domain(struct amd_iommu *iommu);
>  #else
> diff --git a/drivers/iommu/amd/amd_iommu_types.h b/drivers/iommu/amd/amd_iommu_types.h
> index 14f67a8cf755..956fd4658a4a 100644
> --- a/drivers/iommu/amd/amd_iommu_types.h
> +++ b/drivers/iommu/amd/amd_iommu_types.h
> @@ -100,12 +100,15 @@
>  #define FEATURE_HDSUP		BIT_ULL(52)
>  #define FEATURE_SNP		BIT_ULL(63)
>  
> +#define FEATURE_GATS_5LEVEL	1ULL
>  #define FEATURE_GATS_SHIFT	12
>  #define FEATURE_GATS_MASK	(0x03ULL << FEATURE_GATS_SHIFT)
>  
> +#define FEATURE_GLX_3LEVEL	0ULL
>  #define FEATURE_GLX_SHIFT	14
>  #define FEATURE_GLX_MASK	(0x03ULL << FEATURE_GLX_SHIFT)
>  
> +#define FEATURE_PASMAX_16	0xFULL
>  #define FEATURE_PASMAX_SHIFT	32
>  #define FEATURE_PASMAX_MASK	(0x1FULL << FEATURE_PASMAX_SHIFT)
>  
> diff --git a/drivers/iommu/amd/iommu.c b/drivers/iommu/amd/iommu.c
> index 4e4ff1550cf3..c41932e9f16a 100644
> --- a/drivers/iommu/amd/iommu.c
> +++ b/drivers/iommu/amd/iommu.c
> @@ -2822,8 +2822,46 @@ static const struct iommu_dirty_ops amd_dirty_ops = {
>  	.read_and_clear_dirty = amd_iommu_read_and_clear_dirty,
>  };
>  
> +void amd_iommu_build_efr(u64 *efr, u64 *efr2)
> +{
> +	if (efr) {
> +		*efr = (FEATURE_GT | FEATURE_GIOSUP | FEATURE_PPR);
> +
> +		/* 5-level v2 page table support */
> +		*efr |= ((FEATURE_GATS_5LEVEL << FEATURE_GATS_SHIFT) &
> +			 FEATURE_GATS_MASK);
> +
> +		/* 3-level GCR3 table support */
> +		*efr |= ((FEATURE_GLX_3LEVEL << FEATURE_GLX_SHIFT) &
> +			 FEATURE_GLX_MASK);
> +
> +		/* 16-bit PASMAX support */
> +		*efr |= ((FEATURE_PASMAX_16 << FEATURE_PASMAX_SHIFT) &
> +			 FEATURE_PASMAX_MASK);
> +	}
> +
> +	if (efr2)
> +		*efr2 = 0;

Why are you checking for null here? It is never called with null

> +/**
> + * 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 reference a section in the spec for what these are just for
clarity

> + */
> +struct iommu_hw_info_amd {
> +	__u64 efr;
> +	__u64 efr2;
> +};

__aligned_u64

Jason

  reply	other threads:[~2023-12-13 13:27 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-12-12 16:01 [RFC PATCH 0/6] iommu/amd: Introduce hardware info reporting and nested translation support Suravee Suthikulpanit
2023-12-12 16:01 ` [RFC PATCH 1/6] iommu/amd: Update PASID, GATS, and GLX feature related macros Suravee Suthikulpanit
2023-12-12 16:01 ` [RFC PATCH 2/6] iommu/amd: Add support for hw_info for iommu capability query Suravee Suthikulpanit
2023-12-13 13:27   ` Jason Gunthorpe [this message]
2024-01-05 13:39     ` Suthikulpanit, Suravee
2023-12-15  7:32   ` Tian, Kevin
2024-01-05 13:40     ` Suthikulpanit, Suravee
2023-12-12 16:01 ` [RFC PATCH 3/6] iommu/amd: Introduce Guest-ID struct amd_iommu_vminfo Suravee Suthikulpanit
2023-12-15  7:35   ` Tian, Kevin
2024-01-05 13:39     ` Suthikulpanit, Suravee
2024-01-05 14:38       ` Jason Gunthorpe
2024-01-09  9:52         ` Suthikulpanit, Suravee
2023-12-12 16:01 ` [RFC PATCH 4/6] iommufd: Introduce data struct for AMD nested domain allocation Suravee Suthikulpanit
2023-12-13 14:03   ` Jason Gunthorpe
2023-12-15  7:38     ` Tian, Kevin
2024-01-05 13:39     ` Suthikulpanit, Suravee
2023-12-12 16:01 ` [RFC PATCH 5/6] iommu/amd: Introduce helper functions to setup GCR3TRPMode Suravee Suthikulpanit
2023-12-13 13:53   ` Jason Gunthorpe
2023-12-15  7:39     ` Tian, Kevin
2024-01-05 13:56     ` Suthikulpanit, Suravee
2023-12-12 16:01 ` [RFC PATCH 6/6] iommu/amd: Introduce nested translation support Suravee Suthikulpanit
2023-12-13 13:52   ` Jason Gunthorpe
2024-01-05 13:38     ` Suthikulpanit, Suravee
2024-01-05 14:31       ` Jason Gunthorpe
2023-12-15  7:45   ` Tian, Kevin
2024-01-05 13:39     ` Suthikulpanit, Suravee
2024-01-05 14:37       ` Jason Gunthorpe
2024-01-08  6:49         ` Suthikulpanit, Suravee

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20231213132721.GT3014157@nvidia.com \
    --to=jgg@nvidia.com \
    --cc=Dhaval.Giani@amd.com \
    --cc=eric.auger@redhat.com \
    --cc=iommu@lists.linux.dev \
    --cc=jon.grimm@amd.com \
    --cc=joro@8bytes.org \
    --cc=kevin.tian@intel.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=loganodell@google.com \
    --cc=nicolinc@nvidia.com \
    --cc=pandoh@google.com \
    --cc=santosh.shukla@amd.com \
    --cc=suravee.suthikulpanit@amd.com \
    --cc=vasant.hegde@amd.com \
    --cc=yi.l.liu@intel.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox