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

[Daniel Mentz]

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."

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.

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