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
next prev parent 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