linux-arm-kernel.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: Jason Gunthorpe <jgg@nvidia.com>
To: Michael Shavit <mshavit@google.com>
Cc: iommu@lists.linux.dev, linux-arm-kernel@lists.infradead.org,
	linux-kernel@vger.kernel.org, will@kernel.org,
	nicolinc@nvidia.com, tina.zhang@intel.com,
	jean-philippe@linaro.org, robin.murphy@arm.com
Subject: Re: [RFC PATCH v1 6/8] iommu/arm-smmu-v3: Free VMID when uninstalling domain from SMMU
Date: Thu, 17 Aug 2023 15:50:14 -0300	[thread overview]
Message-ID: <ZN5r5q4j8hcuvYt/@nvidia.com> (raw)
In-Reply-To: <20230818021629.RFC.v1.6.I65dd382de382428dcb3cf61342b35405903ac768@changeid>

On Fri, Aug 18, 2023 at 02:16:28AM +0800, Michael Shavit wrote:
> This will allow installing a domain onto multiple smmu devices.
> 
> Signed-off-by: Michael Shavit <mshavit@google.com>
> ---
> 
>  drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c | 13 ++++++++-----
>  1 file changed, 8 insertions(+), 5 deletions(-)

The VMID is basically a different ASID, eg ASID is the cahage tag for
a S1 and VMID is the cache tag for S2.

It is strange that it has a different lifecycle. It seems like the
issue is that the VMID IDA is per smmu while the ASID xarray is
global?

So, I'd suggest consistency. Either the domain ASID/VMID is global and
assigned at allocation time.

Or it is local to the instance, assigned at bind time, and stored in
the domain's attached device list. Some logic is needed to optimize
this - probably keep the instance list sorted by instance.

Having per-instance cache-tags avoids the limit problem a prior patch
was struggling with, at the cost of some more complexity in other
places.

Jason

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

  reply	other threads:[~2023-08-17 18:50 UTC|newest]

Thread overview: 35+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-08-17 18:16 [RFC PATCH v1 0/8] Install domain onto multiple smmus Michael Shavit
2023-08-17 18:16 ` [RFC PATCH v1 1/8] iommu/arm-smmu-v3: Add list of installed_smmus Michael Shavit
2023-08-17 19:05   ` Jason Gunthorpe
2023-08-17 19:34   ` Robin Murphy
2023-08-18  5:34     ` Michael Shavit
2023-08-17 18:16 ` [RFC PATCH v1 2/8] iommu/arm-smmu-v3: Perform invalidations over installed_smmus Michael Shavit
2023-08-17 19:20   ` Jason Gunthorpe
2023-08-17 19:41     ` Robin Murphy
2023-08-18  3:44       ` Michael Shavit
2023-08-18 13:51         ` Jason Gunthorpe
2023-08-21  8:33           ` Michael Shavit
2023-08-21 11:57             ` Jason Gunthorpe
2023-08-22  8:17               ` Michael Shavit
2023-08-22  8:21                 ` Michael Shavit
2023-08-22 10:10                 ` Michael Shavit
2023-08-22 14:15                 ` Jason Gunthorpe
2023-08-17 18:16 ` [RFC PATCH v1 3/8] iommu/arm-smmu-v3-sva: Allocate new ASID from installed_smmus Michael Shavit
2023-08-17 18:38   ` Jason Gunthorpe
2023-08-21  9:31     ` Michael Shavit
2023-08-21 11:54       ` Jason Gunthorpe
2023-08-21 13:38         ` Michael Shavit
2023-08-21 13:50           ` Jason Gunthorpe
2023-08-21 14:16             ` Michael Shavit
2023-08-21 14:26               ` Jason Gunthorpe
2023-08-21 14:39                 ` Michael Shavit
2023-08-21 14:56                   ` Jason Gunthorpe
2023-08-22  8:53                     ` Michael Shavit
2023-08-17 18:16 ` [RFC PATCH v1 4/8] iommu/arm-smmu-v3: check smmu compatibility on attach Michael Shavit
2023-08-17 19:16   ` Robin Murphy
2023-08-18  3:14     ` Michael Shavit
2023-08-17 18:16 ` [RFC PATCH v1 5/8] iommu/arm-smmu-v3: Add arm_smmu_device as a parameter to domain_finalise Michael Shavit
2023-08-17 18:16 ` [RFC PATCH v1 6/8] iommu/arm-smmu-v3: Free VMID when uninstalling domain from SMMU Michael Shavit
2023-08-17 18:50   ` Jason Gunthorpe [this message]
2023-08-17 18:16 ` [RFC PATCH v1 7/8] iommu/arm-smmu-v3: check for domain initialization using pgtbl_ops Michael Shavit
2023-08-17 18:16 ` [RFC PATCH v1 8/8] iommu/arm-smmu-v3: allow multi-SMMU domain installs 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=ZN5r5q4j8hcuvYt/@nvidia.com \
    --to=jgg@nvidia.com \
    --cc=iommu@lists.linux.dev \
    --cc=jean-philippe@linaro.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=tina.zhang@intel.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).