Re: [PATCH] iommu/arm-smmu-v3: Allow disabling Stage 1 translation

[Will Deacon <will@kernel.org>]

On Fri, Apr 24, 2026 at 12:42:56PM -0300, Jason Gunthorpe wrote:
> On Fri, Apr 24, 2026 at 04:16:17PM +0100, Will Deacon wrote:
> > > > > STE/CD is pretty simple now, there is only one place to put the CMO
> > > > > and the ordering is all handled with that shared code. We no longer
> > > > > care about ordering beyond all the writes must be visible to HW before
> > > > > issuing the CMDQ invalidation command - which is the same environment
> > > > > as the pagetable.
> > > > 
> > > > You presumably rely on 64-bit single-copy atomicity for hitless updates,
> > > > no?
> > > 
> > > Yes, just like the page table does..
> > > 
> > > I hope that's not a problem or we have a issue with the PTW :)
> > 
> > You trimmed the part from my reply where I think we _do_ have an issue
> > with the PTW. Here it is again:
> > 
> >   The non-coherent case looks more fragile, because I don't _think_ the
> >   architecture provides any ordering or atomicity guarantees about cache
> >   cleaning to the PoC. Presumably, the correct sequence would be to write
> >   the PTE with the valid bit clear, do the CMO (with completion barrier),
> >   *then* write the bottom byte with the valid bit set and do another CMO.
> 
> I wasn't sure if you are being serious.
> 
> CMO + barriers must provide an ordering guarentee about cache cleaning
> to POC otherwise the entire Linux DMA API is broken. dma_sync must
> order with following device DMA. IMHO that's not negotiable for Linux.

The problem is with concurrent DMA (from the page-table walker) and I
don't see anything that guarantees that in the CPU architecture. I don't
think the streaming DMA API pretends to handle that case, does it? It
relies on a pretty rigid ownership concept from what I understand.

> All ARM iommus rely on 64 bit atomic non tearing. No bugs reported?

It's hard to judge as I don't think SMMUs tend to perform a lot of
speculative address translation when DMA isn't active. 

> Any fix to that is going to have major performance downsides..
> 
> I also strongly suspect it is provided on real HW. It would be hard to
> even build HW where <= 64 bit quanta can tear.
> 
> Maybe this is something ARM should take a look at.

Yes, we should ask. Maybe I missed something in the Arm ARM, but I can
also seeing it being a pain to specify this behaviour all the way out to
the PoC and I wouldn't be so bold as to say that it's hard to build HW
that would exhibit problems here.

> > > And if Samiullah can tackle dma_alloc_coherent then maybe the whole
> > > question is moot.
> > 
> > Yes, that would be great, but we probably need to fix the page-table
> > code too.
> 
> You really want to deal with the likely perf regressions that would
> cause on Android/etc?

Of course I'd rather that the architecture said that our current code
is fine, but if it doesn't then I don't have much choice, really. At the
very least, we should minimise the number of places where we rely on
non-architected behaviour and so keeping the CDs and STEs non-cacheable
remains my preference.

Will