Re: [PATCH v2] iommu/arm-smmu-v3: Align memory attributes for SMMU-originated accesses

[Robin Murphy]

On 05/10/2026 10:26 pm, Daniel Mentz wrote:
> On Mon, Oct 5, 2026 at 9:42 AM Robin Murphy <robin.murphy@xxxxxxx> wrote:
> > This still isn't answering the question of "why?" though. Yes the
> > architecture says some things, but if we were strict about avoiding
> > mismatched attributes then Linux couldn't ever support non-coherent DMA
> > at all! Similarly while the architecture does permit SMMU
> > implementations to be picky about their output attributes, does any such
> > implementation actually exist at all, let alone in a system capable of
> > running mainline Linux?
>
> Fair point that existing implementations have been forgiving in
> practice. My thinking here is simply that a small, self-contained
> cleanup that brings the driver into line with the architecture spec is
> worthwhile on its own merits, even without a known implementation where
> this currently causes problems.
>
> This is really in the same spirit as your commit 7618e4790982
> ("iommu/io-pgtable-arm: Improve attribute handling"), which aligned the
> attribute handling with the architecture specification on the basis
> that:
>
>    "Although the SMMU architectures seem to give some slightly stronger
>     guarantees of Non-Cacheable output types becoming implicitly Outer
>     Shareable in most cases, we may as well be explicit and not take any
>     chances."

That was more about being self-consistent and technically compliant with 
VMSAv7, which again is not relevant to SMMUv3. In fact if we _only_ had 
to support SMMUv3 and not arbitrary other io-pgtable users then we could 
point to 13.1.7 "Ensuring consistent output attributes" to prove that 
that change would not have been necessary.

> As I noted in my reply on the v1 thread [1], under ARM IHI 0070
> (sections 3.15, 6.3.11, and 13.1.2), a non-coherent SMMUv3
> implementation (SMMU_IDR0.COHACC == 0) in which every SMMU-originated
> access configured with Normal Write-Back, Inner Shareable attributes
> fails and records an External Abort (F_STE_FETCH, F_CD_FETCH,
> CERROR_ABT, etc.) is completely architecturally compliant, yet wouldn't
> work with the current arm-smmu-v3 driver.

Sure, and another system could only support iNC-oWB, wherein this change 
still wouldn't work. If you want to argue against making assumptions 
about the implementation/interconnect, you can't simply make a slightly 
different assumption about the implementation/interconnect ;)

In fact for maximum fun, you could even have an interconnect that only 
supports the iWB-oWB-ISH type, but the SMMU is still non-coherent since 
it's in a _different_ inner shareability domain from the CPUs...

Yes, 13.1.2 "Attribute support" says that the system may not support all 
memory types, and unsupported ones may abort, but then equally it says 
"[...] the SMMU is not required to generate attributes that it does not 
use. With the exception of R/W, INST, and PRIV all configuration fields 
that affect unused attributes are IGNORED." And this is why the 
mismatched attributes argument doesn't stand up on its own - without 
knowing the system-specific details of exactly what is being ignored 
from what we think we've programmed, how can we say what the actual 
attributes used to access memory really are, and thus what is or isn't 
mismatched?

Thanks,
Robin.

> It seems reasonable to be explicit here too and program attributes that
> are valid per the spec, rather than relying on the interconnect to
> silently degrade Write-Back attributes to Non-Cacheable.
>
> [1] https://lore.kernel.org/linux-iommu/CAE2F3rACz6Z7X3NNfLWEfjTD9K9YJyYHHyGzcBafEemTFGhgqQ@xxxxxxxxxxxxxx/
>
> Thanks,
> Daniel