Linux IOMMU Development
 help / color / mirror / Atom feed
From: Jason Gunthorpe <jgg@ziepe.ca>
To: Vasant Hegde <vasant.hegde@amd.com>
Cc: iommu@lists.linux.dev, joro@8bytes.org,
	suravee.suthikulpanit@amd.com, wei.huang2@amd.com,
	jsnitsel@redhat.com
Subject: Re: [PATCH v5 11/14] iommu/amd: Add GCR3 [un]initialization function
Date: Fri, 2 Feb 2024 11:17:38 -0400	[thread overview]
Message-ID: <20240202151738.GU50608@ziepe.ca> (raw)
In-Reply-To: <20240118073339.6978-12-vasant.hegde@amd.com>

On Thu, Jan 18, 2024 at 07:33:36AM +0000, Vasant Hegde wrote:
> From: Suravee Suthikulpanit <suravee.suthikulpanit@amd.com>
> 
> These functions are used in PASID to device bind path. In this path
> it checks whether device GCR3 table is setup or not. If not it will
> setup GCR3 table.
> 
> Also in attach device path change default GCR3 table to use MAX
> supported PASIDs. Ideally it should use 1 level PASID table as its
> using PASID zero only. But we don't have support to extend PASID table
> yet. We will fix this later.
> 
> Signed-off-by: Suravee Suthikulpanit <suravee.suthikulpanit@amd.com>
> Co-developed-by: Vasant Hegde <vasant.hegde@amd.com>
> Signed-off-by: Vasant Hegde <vasant.hegde@amd.com>
> ---
>  drivers/iommu/amd/amd_iommu.h |  3 ++
>  drivers/iommu/amd/iommu.c     | 52 +++++++++++++++++++++++++++++++++--
>  2 files changed, 53 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/iommu/amd/amd_iommu.h b/drivers/iommu/amd/amd_iommu.h
> index d5e6315ef9dd..2d099c54b941 100644
> --- a/drivers/iommu/amd/amd_iommu.h
> +++ b/drivers/iommu/amd/amd_iommu.h
> @@ -44,7 +44,10 @@ extern int amd_iommu_guest_ir;
>  extern enum io_pgtable_fmt amd_iommu_pgtable;
>  extern int amd_iommu_gpt_level;
>  
> +/* SVA/PASID */
>  bool amd_iommu_pasid_supported(void);
> +int amd_iommu_gcr3_init(struct iommu_dev_data *dev_data, ioasid_t pasids);
> +void amd_iommu_gcr3_uninit(struct iommu_dev_data *dev_data);
>  
>  /* IOPF */
>  int amd_iommu_iopf_init(struct amd_iommu *iommu);
> diff --git a/drivers/iommu/amd/iommu.c b/drivers/iommu/amd/iommu.c
> index 36a5458a7946..6f5900333946 100644
> --- a/drivers/iommu/amd/iommu.c
> +++ b/drivers/iommu/amd/iommu.c
> @@ -93,6 +93,11 @@ static inline bool pdom_is_v2_pgtbl_mode(struct protection_domain *pdom)
>  	return (pdom && (pdom->pd_mode == PD_MODE_V2));
>  }
>  
> +static inline bool pdom_is_in_pt_mode(struct protection_domain *pdom)
> +{
> +	return (pdom->domain.type == IOMMU_DOMAIN_IDENTITY);
> +}

Why? And what about blocking someday?

Just use dev_data->gcr3_info.gcr3_tbl == NULL to indicate if GCR3 is
loaded or not?

>  /*
>   * Allocate per device domain ID when using V2 page table
>   */
> @@ -1837,6 +1842,46 @@ int amd_iommu_clear_gcr3(struct iommu_dev_data *dev_data, ioasid_t pasid)
>  	return ret;
>  }
>  
> +int amd_iommu_gcr3_init(struct iommu_dev_data *dev_data, ioasid_t pasids)
> +{
> +	struct protection_domain *pdom = dev_data->domain;
> +	int ret = 0;
> +
> +	lockdep_assert_held(&dev_data->lock);
> +
> +	/*
> +	 * We cannot support PASID w/ existing v1 page table in the same domain
> +	 * since it will be nested. However, existing domain w/ v2 page table
> +	 * can be used for PASID.
> +	 */
> +	if (!pdom_is_v2_pgtbl_mode(pdom) && !pdom_is_in_pt_mode(pdom))
> +		return -EOPNOTSUPP;

Put the test directly in the set dev pasid op and it should be more
like

if (!dev_data->gcr3_info.gcr3_tbl && dev_data->domain->type & _IOMMU_DOMAIN_PAGING)
    return -EINVAL;


And you need the mirroring test in alloc_dev to prevent changing the
RID to things the driver does not yet support, I didn't notice that?

> +	/* Allocate GCR3 table */
> +	if (pdom_is_in_pt_mode(pdom) && dev_data->gcr3_info.gcr3_tbl == NULL) {
> +		ret = setup_gcr3_table(&dev_data->gcr3_info,
> +				       dev_to_node(dev_data->dev), pasids);
> +
> +		/* Update device table */
> +		amd_iommu_dev_update_dte(dev_data, true);
> +	}

This shouldn't be any different from do_attach()

> +
> +	return ret;

success oritened flow please

> +void amd_iommu_gcr3_uninit(struct iommu_dev_data *dev_data)
> +{
> +	lockdep_assert_held(&dev_data->lock);
> +
> +	/* Free GCR3 table */
> +	if (pdom_is_in_pt_mode(dev_data->domain)) {
> +		free_gcr3_table(&dev_data->gcr3_info);
> +
> +		/* Update device table */
> +		amd_iommu_dev_update_dte(dev_data, true);
> +	}
> +}

Is it really worth freeing it?

>  static void set_dte_entry(struct amd_iommu *iommu,
>  			  struct iommu_dev_data *dev_data)
>  {
> @@ -1986,9 +2031,12 @@ static int do_attach(struct iommu_dev_data *dev_data,
>  
>  	/* Init GCR3 table and update device table */
>  	if (domain->pd_mode == PD_MODE_V2) {
> -		/* By default, setup GCR3 table to support single PASID */
> +		/*
> +		 * By default, setup GCR3 table to support MAX PASIDs
> +		 * supported by the IOMMU HW.
> +		 */
>  		ret = setup_gcr3_table(&dev_data->gcr3_info,
> -				       dev_to_node(dev_data->dev), 1);
> +				       dev_to_node(dev_data->dev), -1);

-1 should be dev->iommu->max_pasids, but better would be this specific
device's max pasid size, cached from pci_max_pasids()

Jason

  reply	other threads:[~2024-02-02 15:17 UTC|newest]

Thread overview: 45+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-01-18  7:33 [PATCH v5 00/14] iommu/amd: SVA Support (Part 4) - SVA and IOPF Vasant Hegde
2024-01-18  7:33 ` [PATCH v5 01/14] iommu/amd: Rename amd_iommu_v2_supported() as amd_iommu_pasid_supported() Vasant Hegde
2024-01-18  7:33 ` [PATCH v5 02/14] iommu/amd: Introduce per device DTE update function Vasant Hegde
2024-02-02 15:29   ` Jason Gunthorpe
2024-01-18  7:33 ` [PATCH v5 03/14] iommu/amd: Add support for enabling/disabling IOMMU features Vasant Hegde
2024-01-18  7:33 ` [PATCH v5 04/14] iommu/amd: Move PPR-related functions into ppr.c Vasant Hegde
2024-02-02 15:29   ` Jason Gunthorpe
2024-01-18  7:33 ` [PATCH v5 05/14] iommu/amd: Fix PPR interrupt processing logic Vasant Hegde
2024-02-02 15:30   ` Jason Gunthorpe
2024-01-18  7:33 ` [PATCH v5 06/14] iommu/amd: Define per-IOMMU iopf_queue Vasant Hegde
2024-02-02 15:30   ` Jason Gunthorpe
2024-01-18  7:33 ` [PATCH v5 07/14] iommu/amd: Add support for page response Vasant Hegde
2024-02-01 20:20   ` Jason Gunthorpe
2024-02-06 15:39     ` Vasant Hegde
2024-01-18  7:33 ` [PATCH v5 08/14] iommu/amd: Add support for add/remove device for IOPF Vasant Hegde
2024-02-01 21:46   ` Jason Gunthorpe
2024-02-06 16:02     ` Vasant Hegde
2024-01-18  7:33 ` [PATCH v5 09/14] iommu/amd: Add IO page fault notifier handler Vasant Hegde
2024-01-18  7:33 ` [PATCH v5 10/14] iommu/amd: Introduce logic to enable/disable IOPF Vasant Hegde
2024-02-01 21:49   ` Jason Gunthorpe
2024-02-06 16:19     ` Vasant Hegde
2024-02-06 16:36       ` Jason Gunthorpe
2024-02-06 17:29         ` Vasant Hegde
2024-02-06 17:58           ` Jason Gunthorpe
2024-02-07  8:58             ` Vasant Hegde
2024-02-07 12:36               ` Baolu Lu
2024-02-07 18:00                 ` Vasant Hegde
2024-02-08 17:31               ` Jason Gunthorpe
2024-02-08 18:37                 ` Vasant Hegde
2024-02-08 19:03                   ` Jason Gunthorpe
2024-01-18  7:33 ` [PATCH v5 11/14] iommu/amd: Add GCR3 [un]initialization function Vasant Hegde
2024-02-02 15:17   ` Jason Gunthorpe [this message]
2024-02-06 17:00     ` Vasant Hegde
2024-01-18  7:33 ` [PATCH v5 12/14] iommu/amd: Initial SVA support for AMD IOMMU Vasant Hegde
2024-02-02 15:25   ` Jason Gunthorpe
2024-02-06 17:16     ` Vasant Hegde
2024-02-06 17:34       ` Jason Gunthorpe
2024-02-07  9:31         ` Vasant Hegde
2024-02-08 17:41           ` Jason Gunthorpe
2024-02-08 18:23             ` Vasant Hegde
2024-02-08 18:48               ` Jason Gunthorpe
2024-01-18  7:33 ` [PATCH v5 13/14] iommu: Add ops->domain_alloc_sva() Vasant Hegde
2024-01-18  7:33 ` [PATCH v5 14/14] iommu/amd: Add SVA domain support Vasant Hegde
2024-02-02 15:28   ` Jason Gunthorpe
2024-01-18  7:40 ` [PATCH v5 00/14] iommu/amd: SVA Support (Part 4) - SVA and IOPF Vasant Hegde

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=20240202151738.GU50608@ziepe.ca \
    --to=jgg@ziepe.ca \
    --cc=iommu@lists.linux.dev \
    --cc=joro@8bytes.org \
    --cc=jsnitsel@redhat.com \
    --cc=suravee.suthikulpanit@amd.com \
    --cc=vasant.hegde@amd.com \
    --cc=wei.huang2@amd.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