Re: [PATCH v9 3/7] iommu/arm-smmu-v3: Introduce a per-domain arm_smmu_invs array

Will Deacon
2026-01-23T17:51:58Z

On Fri, Jan 23, 2026 at 09:35:58AM -0800, Nicolin Chen wrote:
> On Fri, Jan 23, 2026 at 05:03:10PM +0000, Will Deacon wrote:
> > On Fri, Dec 19, 2025 at 12:11:25PM -0800, Nicolin Chen wrote:
> > > +struct arm_smmu_inv {
> > > + struct arm_smmu_device *smmu;
> > > + u8 type;
> > > + u8 size_opcode;
> > > + u8 nsize_opcode;
> > > + u32 id; /* ASID or VMID or SID */
> > > + union {
> > > + size_t pgsize; /* ARM_SMMU_FEAT_RANGE_INV */
> > > + u32 ssid; /* INV_TYPE_ATS */
> > > + };
> > > +
> > > + refcount_t users; /* users=0 to mark as a trash to be purged */
> >
> > The refcount_t API uses atomics with barrier semantics. Do we actually
> > need those properties when updating the refcounts here? The ASID lock
> > gives us pretty strong serialisation even after this patch series and
> > we rely heavily on that.
>
> But we can't use that mutex in the invalidation function that
> might be an IRQ context?

My question, really, is why do you need the atomic properties in this patch
series? It just looks like overhead at the moment.

Will