From: Nicolin Chen <nicolinc@nvidia.com>
To: <will@kernel.org>
Cc: <jean-philippe@linaro.org>, <robin.murphy@arm.com>,
<joro@8bytes.org>, <jgg@nvidia.com>, <balbirs@nvidia.com>,
<miko.lenczewski@arm.com>, <peterz@infradead.org>,
<kevin.tian@intel.com>, <praan@google.com>,
<linux-arm-kernel@lists.infradead.org>, <iommu@lists.linux.dev>,
<linux-kernel@vger.kernel.org>
Subject: Re: [PATCH v9 0/7] iommu/arm-smmu-v3: Introduce an RCU-protected invalidation array
Date: Mon, 19 Jan 2026 09:10:02 -0800 [thread overview]
Message-ID: <aW5lavfm2mr8GsMb@Asurada-Nvidia> (raw)
In-Reply-To: <cover.1766174731.git.nicolinc@nvidia.com>
Hi Will,
On Fri, Dec 19, 2025 at 12:11:22PM -0800, Nicolin Chen wrote:
> * NVIDIA is building systems with > 10 SMMU instances where > 8 are being
> used concurrently in a single VM. So having 8 copies of an identical S2
> page table is not efficient. Instead, all vSMMU instances should check
> compatibility on a shared S2 iopt, to eliminate 7 copies.
>
> Previous attempt based on the list/spinlock design:
> iommu/arm-smmu-v3: Allocate vmid per vsmmu instead of s2_parent
> https://lore.kernel.org/all/cover.1744692494.git.nicolinc@nvidia.com/
> now can adopt this invs array, avoiding adding complex lists/locks.
>
> * The guest support for BTM requires temporarily invalidating two ASIDs
> for a single instance. When it renumbers ASIDs this can now be done via
> the invs array.
>
> * SVA with multiple devices being used by a single process (NVIDIA today
> has 4-8) sequentially iterates the invalidations through all instances.
> This ignores the HW concurrency available in each instance. It would be
> nice to not spin on each sync but go forward and issue batches to other
> instances also. Reducing to a single SVA domain shared across instances
> is required to look at this.
>
> This is on Github:
> https://github.com/nicolinc/iommufd/commits/arm_smmu_invs-v9
>
> Changelog
> v9:
> * Set cur->ssid correctly in arm_smmu_master_build_inv()
> * Add comments for INV_TYPE_S1_ASID in arm_smmu_master_build_inv()
Sorry for a gentle push. This has been sitting here for a while.
And we are at rc6. Any chance that it can make it to this cycle?
We have a dependent series that I am about to send v2:
https://lore.kernel.org/linux-iommu/cover.1766088962.git.nicolinc@nvidia.com/
Anything that you think I should improve, please let me know.
Thanks!
Nicolin
prev parent reply other threads:[~2026-01-19 17:10 UTC|newest]
Thread overview: 45+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-12-19 20:11 [PATCH v9 0/7] iommu/arm-smmu-v3: Introduce an RCU-protected invalidation array Nicolin Chen
2025-12-19 20:11 ` [PATCH v9 1/7] iommu/arm-smmu-v3: Explicitly set smmu_domain->stage for SVA Nicolin Chen
2026-01-23 9:49 ` Pranjal Shrivastava
2025-12-19 20:11 ` [PATCH v9 2/7] iommu/arm-smmu-v3: Add an inline arm_smmu_domain_free() Nicolin Chen
2026-01-23 9:50 ` Pranjal Shrivastava
2025-12-19 20:11 ` [PATCH v9 3/7] iommu/arm-smmu-v3: Introduce a per-domain arm_smmu_invs array Nicolin Chen
2026-01-23 9:53 ` Pranjal Shrivastava
2026-01-23 17:03 ` Will Deacon
2026-01-23 17:35 ` Nicolin Chen
2026-01-23 17:51 ` Will Deacon
2026-01-23 17:56 ` Nicolin Chen
2026-01-23 19:16 ` Jason Gunthorpe
2026-01-23 19:18 ` Nicolin Chen
2026-01-26 14:54 ` Will Deacon
2026-01-26 15:21 ` Jason Gunthorpe
2025-12-19 20:11 ` [PATCH v9 4/7] iommu/arm-smmu-v3: Pre-allocate a per-master invalidation array Nicolin Chen
2026-01-23 9:54 ` Pranjal Shrivastava
2025-12-19 20:11 ` [PATCH v9 5/7] iommu/arm-smmu-v3: Populate smmu_domain->invs when attaching masters Nicolin Chen
2025-12-19 20:11 ` [PATCH v9 6/7] iommu/arm-smmu-v3: Add arm_smmu_invs based arm_smmu_domain_inv_range() Nicolin Chen
2026-01-23 9:48 ` Pranjal Shrivastava
2026-01-23 13:56 ` Jason Gunthorpe
2026-01-27 16:38 ` Nicolin Chen
2026-01-27 17:08 ` Jason Gunthorpe
2026-01-27 18:07 ` Nicolin Chen
2026-01-27 18:23 ` Jason Gunthorpe
2026-01-27 18:37 ` Nicolin Chen
2026-01-27 19:19 ` Jason Gunthorpe
2026-01-27 20:14 ` Nicolin Chen
2026-01-28 0:05 ` Jason Gunthorpe
2026-01-23 17:05 ` Will Deacon
2026-01-23 17:10 ` Will Deacon
2026-01-23 17:43 ` Nicolin Chen
2026-01-23 20:03 ` Jason Gunthorpe
2026-01-26 13:01 ` Will Deacon
2026-01-26 15:20 ` Jason Gunthorpe
2026-01-26 16:02 ` Will Deacon
2026-01-26 16:09 ` Jason Gunthorpe
2026-01-26 18:56 ` Will Deacon
2026-01-27 3:14 ` Nicolin Chen
2026-01-26 17:50 ` Nicolin Chen
2025-12-19 20:11 ` [PATCH v9 7/7] iommu/arm-smmu-v3: Perform per-domain invalidations using arm_smmu_invs Nicolin Chen
2026-01-23 17:07 ` Will Deacon
2026-01-23 17:47 ` Nicolin Chen
2026-01-23 19:59 ` Jason Gunthorpe
2026-01-19 17:10 ` Nicolin Chen [this message]
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=aW5lavfm2mr8GsMb@Asurada-Nvidia \
--to=nicolinc@nvidia.com \
--cc=balbirs@nvidia.com \
--cc=iommu@lists.linux.dev \
--cc=jean-philippe@linaro.org \
--cc=jgg@nvidia.com \
--cc=joro@8bytes.org \
--cc=kevin.tian@intel.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=miko.lenczewski@arm.com \
--cc=peterz@infradead.org \
--cc=praan@google.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox