From: Jason Gunthorpe <jgg@nvidia.com>
To: Nicolin Chen <nicolinc@nvidia.com>
Cc: will@kernel.org, robin.murphy@arm.com, joro@8bytes.org,
jpb@kernel.org, praan@google.com, miko.lenczewski@arm.com,
linux-arm-kernel@lists.infradead.org, iommu@lists.linux.dev,
linux-kernel@vger.kernel.org, patches@lists.linux.dev
Subject: Re: [PATCH v1 2/9] iommu/arm-smmu-v3: Add alloc_id/free_id functions to arm_smmu_invs
Date: Fri, 16 Jan 2026 10:41:20 -0400 [thread overview]
Message-ID: <20260116144120.GM961588@nvidia.com> (raw)
In-Reply-To: <aWnI3Ii3KCFmJV3/@Asurada-Nvidia>
On Thu, Jan 15, 2026 at 09:13:00PM -0800, Nicolin Chen wrote:
> On Fri, Jan 02, 2026 at 11:57:15AM -0400, Jason Gunthorpe wrote:
> > On Tue, Dec 30, 2025 at 10:52:53AM -0800, Nicolin Chen wrote:
> > > Hi Jason,
> > >
> > > On Fri, Dec 19, 2025 at 01:05:51PM -0400, Jason Gunthorpe wrote:
> > > > +static int arm_smmu_get_tag(struct arm_smmu_domain *smmu_domain,
> > > > + struct arm_smmu_master *master,
> > > > + struct arm_vsmmu *vsmmu,
> > > > + struct arm_smmu_iotlb_tag *tag, bool no_alloc)
> > > [...]
> > > > + case ARM_SMMU_DOMAIN_S2:
> > > > + if (smmu_domain->nest_parent) {
> > > > + /* FIXME we can support attaching a nest_parent without
> > > > + * a vsmmu, but to do that we need to fix
> > > > + * arm_smmu_get_id_from_invs() to never return the vmid
> > > > + * of a vsmmu. Probably by making a
> > > > + * INV_TYPE_S2_VMID_VSMMU */
> > > > + id = vsmmu->vmid;
> > > > + return 0;
> > > > + }
> > >
> > > Would you mind elaborating why arm_smmu_get_id_from_invs() can't
> > > return vsmmu->vmid to share with a naked S2 STE?
> >
> > A "naked" S2 domain doesn't have a pointer to the vsmmu, so it is
> > impossible to get vsmmu->vmid.
>
> An S2 parent domain should be per VM. And a vSMMU on top of an S2
> should be per SMMU. So, it could have stored a list of vSMMUs and
> device attaching to a naked S2 could match its master->smmu with
> vSMMU->smmu in the list?
That would cause lifecycle problems if the vSMMU is destroyed
while the nake S2 is still attached and trying to use the vSMMU's
VMID.
Jason
next prev parent reply other threads:[~2026-01-16 14:41 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-12-18 20:26 [PATCH v1 0/9] iommu/arm-smmu-v3: Share domain across SMMU/vSMMU instances Nicolin Chen
2025-12-18 20:26 ` [PATCH v1 1/9] iommu/arm-smmu-v3: Pass in ssid to arm_smmu_make_s1_cd() Nicolin Chen
2025-12-18 20:26 ` [PATCH v1 2/9] iommu/arm-smmu-v3: Add alloc_id/free_id functions to arm_smmu_invs Nicolin Chen
2025-12-19 17:05 ` Jason Gunthorpe
2025-12-19 20:56 ` Nicolin Chen
2026-01-02 15:54 ` Jason Gunthorpe
2025-12-30 18:52 ` Nicolin Chen
2025-12-31 19:48 ` Nicolin Chen
2026-01-02 15:57 ` Jason Gunthorpe
2026-01-16 5:13 ` Nicolin Chen
2026-01-16 14:41 ` Jason Gunthorpe [this message]
2026-01-16 16:58 ` Nicolin Chen
2026-01-16 17:11 ` Jason Gunthorpe
2026-01-16 18:27 ` Nicolin Chen
2026-01-17 1:11 ` Jason Gunthorpe
2025-12-18 20:26 ` [PATCH v1 3/9] iommu/arm-smmu-v3: Store ASIDs and VMID in arm_smmu_master Nicolin Chen
2025-12-19 15:16 ` Jason Gunthorpe
2025-12-19 19:17 ` Nicolin Chen
2025-12-18 20:26 ` [PATCH v1 4/9] iommu/arm-smmu-v3: Use alloc_id/free_id ops in arm_smmu_invs_merge/unref Nicolin Chen
2025-12-18 20:26 ` [PATCH v1 5/9] iommu/arm-smmu-v3: Install to CD/STE the ASID/VMID stored in the master Nicolin Chen
2025-12-18 20:26 ` [PATCH v1 6/9] iommu/arm-smmu-v3: Use dummy ASID/VMID in arm_smmu_master_build_invs() Nicolin Chen
2025-12-18 20:26 ` [PATCH v1 7/9] iommu/arm-smmu-v3: Remove free_fn argument from arm_smmu_invs_unref() Nicolin Chen
2025-12-18 20:26 ` [PATCH v1 8/9] iommu/arm-smmu-v3: Remove ASID/VMID from arm_smmu_domain Nicolin Chen
2025-12-18 20:26 ` [PATCH v1 9/9] iommu/arm-smmu-v3: Allow sharing domain across SMMUs Nicolin Chen
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=20260116144120.GM961588@nvidia.com \
--to=jgg@nvidia.com \
--cc=iommu@lists.linux.dev \
--cc=joro@8bytes.org \
--cc=jpb@kernel.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=miko.lenczewski@arm.com \
--cc=nicolinc@nvidia.com \
--cc=patches@lists.linux.dev \
--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