[PATCH v9 6/7] iommu/arm-smmu-v3: Add arm_smmu_invs based arm_smmu_domain_inv_range()
Jason Gunthorpe
jgg at nvidia.com
Fri Jan 23 12:03:27 PST 2026
On Fri, Jan 23, 2026 at 05:10:52PM +0000, Will Deacon wrote:
> On Fri, Jan 23, 2026 at 05:05:31PM +0000, Will Deacon wrote:
> > On Fri, Dec 19, 2025 at 12:11:28PM -0800, Nicolin Chen wrote:
> > > + /*
> > > + * We are committed to updating the STE. Ensure the invalidation array
> > > + * is visible to concurrent map/unmap threads, and acquire any racing
> > > + * IOPTE updates.
> > > + *
> > > + * [CPU0] | [CPU1]
> > > + * |
> > > + * change IOPTEs and TLB flush: |
> > > + * arm_smmu_domain_inv_range() { | arm_smmu_install_old_domain_invs {
> > > + * ... | rcu_assign_pointer(new_invs);
> > > + * smp_mb(); // ensure IOPTEs | smp_mb(); // ensure new_invs
> > > + * ... | kfree_rcu(old_invs, rcu);
> > > + * // load invalidation array | }
> > > + * invs = rcu_dereference(); | arm_smmu_install_ste_for_dev {
> > > + * | STE = TTB0 // read new IOPTEs
> > > + */
> > > + smp_mb();
> >
> > I don't think we need to duplicate this comment three times, you can just
> > refer to the first function (e.g. "See ordering comment in
> > arm_smmu_domain_inv_range()").
> >
> > However, isn't the comment above misleading for this case?
> > arm_smmu_install_old_domain_invs() has the sequencing the other way
> > around on CPU 1: we should update the STE first.
>
> I also think we probably want a dma_mb() instead of an smp_mb() for all
> of these examples? It won't make any practical difference but I think it
> helps readability given that one of the readers is the PTW.
The only actual dma_wmb() is inside arm_smmu_install_ste_for_dev()
after updating the STE. Adding that line explicitly would help as that
is the only point where we must have the writes actually visible to
the DMA HW.
The ones written here as smp_mb() are not required to be DMA ones and
could all be NOP's on UP..
Jason
More information about the linux-arm-kernel
mailing list