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 12/14] iommu/amd: Initial SVA support for AMD IOMMU
Date: Thu, 8 Feb 2024 14:48:47 -0400	[thread overview]
Message-ID: <20240208184847.GX31743@ziepe.ca> (raw)
In-Reply-To: <5ce55e42-d158-1675-f906-58b545e2b2b6@amd.com>

On Thu, Feb 08, 2024 at 11:53:58PM +0530, Vasant Hegde wrote:
> >> We are doing 1 SVA domain : 1 PASID : N devices model. That means we need to
> >> check all these things while attaching *first* PASID to device. (That's what we
> >> had discussed sometime back when I had all these things in feature_enable(SVA)
> >> path).
> > 
> > I thought I said you 1 PASID is not technically correct, but you could
> > get away it it for a short term. You should be planning to support N
> > PASIDs because that is what the API defines.
> 
> I am describing API in SVA context only. In that flow once we allocate a SVA
> domain for a PASID, then all devices for that PASID is attached to
> same domain.

It is OK to take a shortcut here if it helps, but that is not the API
model. Domains, SVA or not, do not have PASIDs. The only place a PASID
comes is via the set_dev_pasid() argument and any domain should be
attachable to any combination of PASIDs.

So the only place a PASID should be stored is in the elements of the
invalidation tracking list of the domain. When you get that all
completed it should all be uniform and a limitation like this should
go away. But this is fine to hold over for a followup that completes
the PASID support.

> > You just trivially check these conditions at the top of set_dev_pasid, look at
> > what I did for ARM:
> > 
> > 	if (smmu_domain->smmu != master->smmu || pasid == IOMMU_NO_PASID)
> > 		return -EINVAL;
> > 
> > 	if (!master->cd_table.in_ste &&
> > 	    sid_domain->type != IOMMU_DOMAIN_IDENTITY &&
> > 	    sid_domain->type != IOMMU_DOMAIN_BLOCKED)
> > 		return -EINVAL;
> > 
> > For AMD "cd_table in_ste" means that the DTE points to a GCR3 table
> > already. This is trivially tracked in the DTE programming in set_dte
> > because you know if the dte is being configured with a GCR3 or not.
> > 
> > The other cases represent the situations where we know how to upgrade a DTE
> > for those domains to one with a GCR3. Everything else is blocked.
> 
> I got something similar. I have reworked set/remove pasid path completely.
> I will try to post it soon.

Nice!

Jason

  reply	other threads:[~2024-02-08 18:48 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
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 [this message]
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=20240208184847.GX31743@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