From: Jason Gunthorpe <jgg@nvidia.com>
To: Baolu Lu <baolu.lu@linux.intel.com>
Cc: Michael Shavit <mshavit@google.com>,
Will Deacon <will@kernel.org>,
Robin Murphy <robin.murphy@arm.com>,
Joerg Roedel <joro@8bytes.org>,
jean-philippe@linaro.org, nicolinc@nvidia.com,
linux-arm-kernel@lists.infradead.org, iommu@lists.linux.dev,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH v2 14/18] iommu/arm-smmu-v3: Support domains with shared CDs
Date: Thu, 8 Jun 2023 10:39:28 -0300 [thread overview]
Message-ID: <ZIHaEFJFVQqvJvmU@nvidia.com> (raw)
In-Reply-To: <f0a691fa-d050-f457-9c8d-0ae340eab58f@linux.intel.com>
On Thu, Jun 08, 2023 at 10:39:23AM +0800, Baolu Lu wrote:
> On 6/7/23 7:59 PM, Jason Gunthorpe wrote:
> > On Wed, Jun 07, 2023 at 12:06:07AM +0530, Michael Shavit wrote:
> > > > What we definately shouldn't do is try to have different SVA
> > > > iommu_domain's pointing at the same ASID. That is again making SVA
> > > > special, which we are trying to get away from 😄
> > > Fwiw, this change is preserving the status-quo in that regard;
> > > arm-smmu-v3-sva.c is already doing this. But yes, I agree that
> > > resolving the limitation is a better long term solution... and
> > > something I can try to look at further.
> > I suppose we also don't really have a entirely clear picture what
> > allocating multiple SVA domains should even do in the iommu driver.
> >
> > The driver would like to share the ASID, but things are much cleaner
> > for everything if the driver model has ASID 1:1 with the iommu_domain.
>
> This means that each ASID should be mapped to a single IOMMU domain.
> This is conceptually right as iommu_domain represents a hardware page
> table. For SVA, it's an mm_struct.
>
> So in my mind, each sva_domain should have a 1:1 relationship with an
> mm_struct.
If we want to support multiple iommu drivers then we should support
multiple iommu_domains per mm_struct so that each driver can have its
own. In this world if each instance wants its own iommu_domain it is
not a big deal.
Drivers that can share iommu_domains across instances should probably
also share sva iommu_domains across instances.
Most real systems have only one iommu driver and we'd like the good
iommu drivers to be able to share domains across instances, so we'd
expect only 1 iommu_domain per mm struct.
Jason
WARNING: multiple messages have this Message-ID (diff)
From: Jason Gunthorpe <jgg@nvidia.com>
To: Baolu Lu <baolu.lu@linux.intel.com>
Cc: Michael Shavit <mshavit@google.com>,
Will Deacon <will@kernel.org>,
Robin Murphy <robin.murphy@arm.com>,
Joerg Roedel <joro@8bytes.org>,
jean-philippe@linaro.org, nicolinc@nvidia.com,
linux-arm-kernel@lists.infradead.org, iommu@lists.linux.dev,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH v2 14/18] iommu/arm-smmu-v3: Support domains with shared CDs
Date: Thu, 8 Jun 2023 10:39:28 -0300 [thread overview]
Message-ID: <ZIHaEFJFVQqvJvmU@nvidia.com> (raw)
In-Reply-To: <f0a691fa-d050-f457-9c8d-0ae340eab58f@linux.intel.com>
On Thu, Jun 08, 2023 at 10:39:23AM +0800, Baolu Lu wrote:
> On 6/7/23 7:59 PM, Jason Gunthorpe wrote:
> > On Wed, Jun 07, 2023 at 12:06:07AM +0530, Michael Shavit wrote:
> > > > What we definately shouldn't do is try to have different SVA
> > > > iommu_domain's pointing at the same ASID. That is again making SVA
> > > > special, which we are trying to get away from 😄
> > > Fwiw, this change is preserving the status-quo in that regard;
> > > arm-smmu-v3-sva.c is already doing this. But yes, I agree that
> > > resolving the limitation is a better long term solution... and
> > > something I can try to look at further.
> > I suppose we also don't really have a entirely clear picture what
> > allocating multiple SVA domains should even do in the iommu driver.
> >
> > The driver would like to share the ASID, but things are much cleaner
> > for everything if the driver model has ASID 1:1 with the iommu_domain.
>
> This means that each ASID should be mapped to a single IOMMU domain.
> This is conceptually right as iommu_domain represents a hardware page
> table. For SVA, it's an mm_struct.
>
> So in my mind, each sva_domain should have a 1:1 relationship with an
> mm_struct.
If we want to support multiple iommu drivers then we should support
multiple iommu_domains per mm_struct so that each driver can have its
own. In this world if each instance wants its own iommu_domain it is
not a big deal.
Drivers that can share iommu_domains across instances should probably
also share sva iommu_domains across instances.
Most real systems have only one iommu driver and we'd like the good
iommu drivers to be able to share domains across instances, so we'd
expect only 1 iommu_domain per mm struct.
Jason
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next prev parent reply other threads:[~2023-06-08 13:39 UTC|newest]
Thread overview: 70+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-06-06 12:07 [PATCH v2 00/18] Add PASID support to SMMUv3 unmanaged domains Michael Shavit
2023-06-06 12:07 ` Michael Shavit
2023-06-06 12:07 ` [PATCH v2 01/18] iommu/arm-smmu-v3: Move ctx_desc out of s1_cfg Michael Shavit
2023-06-06 12:07 ` Michael Shavit
2023-06-06 12:07 ` [PATCH v2 02/18] iommu/arm-smmu-v3: Add smmu_s1_cfg to smmu_master Michael Shavit
2023-06-06 12:07 ` Michael Shavit
2023-06-06 12:07 ` [PATCH v2 03/18] iommu/arm-smmu-v3: Refactor write_strtab_ent Michael Shavit
2023-06-06 12:07 ` Michael Shavit
2023-06-06 12:07 ` [PATCH v2 04/18] iommu/arm-smmu-v3: Refactor write_ctx_desc Michael Shavit
2023-06-06 12:07 ` Michael Shavit
2023-06-06 12:07 ` [PATCH v2 05/18] iommu/arm-smmu-v3: Use the master-owned s1_cfg Michael Shavit
2023-06-06 12:07 ` Michael Shavit
2023-06-06 12:07 ` [PATCH v2 06/18] iommu/arm-smmu-v3: Simplify arm_smmu_enable_ats Michael Shavit
2023-06-06 12:07 ` Michael Shavit
2023-06-06 12:07 ` [PATCH v2 07/18] iommu/arm-smmu-v3: Keep track of attached ssids Michael Shavit
2023-06-06 12:07 ` Michael Shavit
2023-06-06 12:07 ` [PATCH v2 08/18] iommu/arm-smmu-v3: Add helper for atc invalidation Michael Shavit
2023-06-06 12:07 ` Michael Shavit
2023-06-06 12:07 ` [PATCH v2 09/18] iommu/arm-smmu-v3: Implement set_dev_pasid Michael Shavit
2023-06-06 12:07 ` Michael Shavit
2023-06-06 12:07 ` [PATCH v2 10/18] iommu/arm-smmu-v3-sva: Remove bond refcount Michael Shavit
2023-06-06 12:07 ` Michael Shavit
2023-06-06 12:07 ` [PATCH v2 11/18] iommu/arm-smmu-v3-sva: Clean unused iommu_sva Michael Shavit
2023-06-06 12:07 ` Michael Shavit
2023-06-06 12:07 ` [PATCH v2 12/18] iommu/arm-smmu-v3-sva: Remove arm_smmu_bond Michael Shavit
2023-06-06 12:07 ` Michael Shavit
2023-06-06 12:07 ` [PATCH v2 13/18] iommu/arm-smmu-v3-sva: Add check when enabling sva Michael Shavit
2023-06-06 12:07 ` Michael Shavit
2023-06-06 12:07 ` [PATCH v2 14/18] iommu/arm-smmu-v3: Support domains with shared CDs Michael Shavit
2023-06-06 12:07 ` Michael Shavit
2023-06-06 17:09 ` Jason Gunthorpe
2023-06-06 17:09 ` Jason Gunthorpe
2023-06-06 18:36 ` Michael Shavit
2023-06-06 18:36 ` Michael Shavit
2023-06-07 11:59 ` Jason Gunthorpe
2023-06-07 11:59 ` Jason Gunthorpe
2023-06-08 2:39 ` Baolu Lu
2023-06-08 2:39 ` Baolu Lu
2023-06-08 13:39 ` Jason Gunthorpe [this message]
2023-06-08 13:39 ` Jason Gunthorpe
2023-06-09 1:44 ` Baolu Lu
2023-06-09 1:44 ` Baolu Lu
2023-06-14 9:17 ` Michael Shavit
2023-06-14 9:17 ` Michael Shavit
2023-06-14 9:43 ` Michael Shavit
2023-06-14 9:43 ` Michael Shavit
2023-06-14 9:57 ` Robin Murphy
2023-06-14 9:57 ` Robin Murphy
2023-06-14 12:10 ` Jason Gunthorpe
2023-06-14 12:10 ` Jason Gunthorpe
2023-06-14 13:30 ` Michael Shavit
2023-06-14 13:30 ` Michael Shavit
2023-06-14 13:35 ` Jason Gunthorpe
2023-06-14 13:35 ` Jason Gunthorpe
2023-07-05 9:56 ` Zhang, Tina
2023-07-05 9:56 ` Zhang, Tina
2023-07-10 16:55 ` Jason Gunthorpe
2023-07-10 16:55 ` Jason Gunthorpe
2023-07-11 0:26 ` Zhang, Tina
2023-07-11 0:26 ` Zhang, Tina
2023-07-11 13:53 ` Jason Gunthorpe
2023-07-11 13:53 ` Jason Gunthorpe
2023-06-06 12:07 ` [PATCH v2 15/18] iommu/arm-smmu-v3: Allow more re-use for SVA Michael Shavit
2023-06-06 12:07 ` Michael Shavit
2023-06-06 12:07 ` [PATCH v2 16/18] iommu/arm-smmu-v3-sva: Attach S1_SHARED_CD domain Michael Shavit
2023-06-06 12:07 ` Michael Shavit
2023-06-06 12:07 ` [PATCH v2 17/18] iommu/arm-smmu-v3-sva: Alloc notifier for {smmu,mn} Michael Shavit
2023-06-06 12:07 ` Michael Shavit
2023-06-06 12:07 ` [PATCH v2 18/18] iommu/arm-smmu-v3-sva: Remove atc_inv_domain_ssid Michael Shavit
2023-06-06 12:07 ` Michael Shavit
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=ZIHaEFJFVQqvJvmU@nvidia.com \
--to=jgg@nvidia.com \
--cc=baolu.lu@linux.intel.com \
--cc=iommu@lists.linux.dev \
--cc=jean-philippe@linaro.org \
--cc=joro@8bytes.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mshavit@google.com \
--cc=nicolinc@nvidia.com \
--cc=robin.murphy@arm.com \
--cc=will@kernel.org \
/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.