All of lore.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.