From: Nicolin Chen <nicolinc@nvidia.com>
To: Jason Gunthorpe <jgg@nvidia.com>
Cc: <will@kernel.org>, <robin.murphy@arm.com>, <joro@8bytes.org>,
<kevin.tian@intel.com>, <praan@google.com>, <nathan@kernel.org>,
<yi.l.liu@intel.com>, <peterz@infradead.org>,
<mshavit@google.com>, <jsnitsel@redhat.com>,
<smostafa@google.com>, <jeff.johnson@oss.qualcomm.com>,
<zhangzekun11@huawei.com>, <linux-arm-kernel@lists.infradead.org>,
<iommu@lists.linux.dev>, <linux-kernel@vger.kernel.org>,
<shameerali.kolothum.thodi@huawei.com>
Subject: Re: [PATCH v2 06/11] iommu/arm-smmu-v3: Introduce arm_smmu_s2_parent_tlb_ invalidation helpers
Date: Tue, 15 Apr 2025 13:10:37 -0700 [thread overview]
Message-ID: <Z/69PTDANYagKX3d@Asurada-Nvidia> (raw)
In-Reply-To: <20250415125042.GA517881@nvidia.com>
On Tue, Apr 15, 2025 at 09:50:42AM -0300, Jason Gunthorpe wrote:
> struct invalidation_op {
> struct arm_smmu_device *smmu;
> enum {ATS,S2_VMDIA_IPA,S2_VMID,S1_ASID} invalidation_op;
> union {
> u16 vmid;
> u32 asid;
> u32 ats_id;
> };
> refcount_t users;
> };
>
> Then invalidation would just iterate over this list following each
> instruction.
>
> When things are attached the list is mutated:
> - Normal S1/S2 attach would reuse an ASID for the same instance or
> allocate a new list entry, users keeps track of ID sharing
> - VMID attach would use the VMID of the vSMMU
> - ATS enabled would add entries for each PCI device instead of the
> seperate ATS list
Interesting. I can see it generalize all the use cases.
Yet are you expecting a big list combining TLBI and ATC_INV cmds?
I think the ATC_INV entries doesn't need a refcount? And finding
an SID (to remove the device for example) would take long, when
there are a lot of entries in the list?
Should the ATS list still be separate, or even an xarray?
> To do this without locking on the invalidation side would require
> using RCU to manage the list, which suggests it is probably an array
> that is re-allocated each time it is changed.
>
> That means some fancy algorithms to copy and mutate the array, deal
> with error cases and sort it (ATS must follow ID, want things grouped
> by instance).
>
> There is some tricky memory barriers needed and RCU would require that
> SMMU unplug do a synchronize_rcu(). IIRC riscv did this in their
> driver.
I will refer to their driver. Yet, I wonder what we will gain from
RCU here? Race condition? Would you elaborate with some use case?
> But the end result is we fully disconnect the domain from the smmu
> instance and all domain types can be shared across all instances if
> they support the pagetable layout. The invalidation also becomes
> somewhat simpler as it just sweeps the list and does what it is
> told. The special ATS list, counter and locking is removed too.
OK. I'd like to give it another try. Or would you prefer to write
yourself?
Thanks
Nicolin
next prev parent reply other threads:[~2025-04-15 20:11 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-04-15 4:57 [PATCH v2 00/11] iommu/arm-smmu-v3: Allocate vmid per vsmmu instead of s2_parent Nicolin Chen
2025-04-15 4:57 ` [PATCH v2 01/11] iommu/arm-smmu-v3: Pass in vmid to arm_smmu_make_s2_domain_ste() Nicolin Chen
2025-04-15 4:57 ` [PATCH v2 02/11] iommu/arm-smmu-v3: Pass in smmu/iommu_domain to __arm_smmu_tlb_inv_range() Nicolin Chen
2025-05-15 15:06 ` Will Deacon
2025-04-15 4:57 ` [PATCH v2 03/11] iommu/arm-smmu-v3: Share cmdq/cmd helpers with arm-smmu-v3-iommufd Nicolin Chen
2025-04-15 4:57 ` [PATCH v2 04/11] iommu/arm-smmu-v3: Add an inline arm_smmu_tlb_inv_vmid helper Nicolin Chen
2025-04-15 4:57 ` [PATCH v2 05/11] iommu/arm-smmu-v3: Rename arm_smmu_attach_prepare_vmaster Nicolin Chen
2025-04-15 4:57 ` [PATCH v2 06/11] iommu/arm-smmu-v3: Introduce arm_smmu_s2_parent_tlb_ invalidation helpers Nicolin Chen
2025-04-15 12:50 ` Jason Gunthorpe
2025-04-15 20:10 ` Nicolin Chen [this message]
2025-04-15 23:46 ` Jason Gunthorpe
2025-04-15 4:57 ` [PATCH v2 07/11] iommu/arm-smmu-v3: Introduce arm_vsmmu_atc_inv_domain() Nicolin Chen
2025-04-15 4:57 ` [PATCH v2 08/11] iommu/arm-smmu-v3: Use vSMMU helpers for S2 and ATC invalidations Nicolin Chen
2025-04-15 4:57 ` [PATCH v2 09/11] iommu/arm-smmu-v3: Clean up nested_ats_flush from master_domain Nicolin Chen
2025-04-15 4:57 ` [PATCH v2 10/11] iommu/arm-smmu-v3: Decouple vmid from S2 nest_parent domain Nicolin Chen
2025-04-15 4:57 ` [PATCH v2 11/11] iommu/arm-smmu-v3: Allow to share S2 nest_parent domain across vSMMUs 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=Z/69PTDANYagKX3d@Asurada-Nvidia \
--to=nicolinc@nvidia.com \
--cc=iommu@lists.linux.dev \
--cc=jeff.johnson@oss.qualcomm.com \
--cc=jgg@nvidia.com \
--cc=joro@8bytes.org \
--cc=jsnitsel@redhat.com \
--cc=kevin.tian@intel.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mshavit@google.com \
--cc=nathan@kernel.org \
--cc=peterz@infradead.org \
--cc=praan@google.com \
--cc=robin.murphy@arm.com \
--cc=shameerali.kolothum.thodi@huawei.com \
--cc=smostafa@google.com \
--cc=will@kernel.org \
--cc=yi.l.liu@intel.com \
--cc=zhangzekun11@huawei.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