public inbox for linux-arm-kernel@lists.infradead.org
 help / color / mirror / Atom feed
From: Will Deacon <will@kernel.org>
To: Jason Gunthorpe <jgg@ziepe.ca>
Cc: Robin Murphy <robin.murphy@arm.com>,
	Dawei Li <dawei.li@linux.dev>,
	joro@8bytes.org, linux-arm-kernel@lists.infradead.org,
	iommu@lists.linux.dev, linux-kernel@vger.kernel.org,
	set_pte_at@outlook.com, stable@vger.kernel.org
Subject: Re: [PATCH] iommu/arm-smmu-v3: Maintain valid access attributes for non-coherent SMMU
Date: Tue, 20 Jan 2026 12:14:43 +0000	[thread overview]
Message-ID: <aW9xs1ko3nWq5VbS@willie-the-truck> (raw)
In-Reply-To: <20260105185423.GI125261@ziepe.ca>

On Mon, Jan 05, 2026 at 02:54:23PM -0400, Jason Gunthorpe wrote:
> On Mon, Jan 05, 2026 at 04:02:34PM +0000, Robin Murphy wrote:
> 
> > > It is reasonable that Linux will set the attributes properly based on
> > > what it is doing. Setting the wrong attributes and expecting the HW to
> > > ignore them seems like a hacky direction.
> > 
> > Oh, I'm not saying that we *shouldn't* set our attributes more exactly -
> > this would still be needed for doing things the "right" way too - I just
> > want to be very clear on the reasons why. 
> 
> At least I know of HW where the SMMU fetches covered by COHACC:
> 
>  * Translation table walks.
>  * Fetches of L1STD, STE, L1CD and CD.
>  * Command queue, Event queue and PRI queue access.
>  * GERROR, CMD_SYNC, Event queue and PRI queue MSIs, if supported.
> 
> Have a mixture of coherency support. The SOC has multiple fabrics, one
> non-coherent one specifically for isochronous traffic.  In HW some
> SMMU sub-units (like the table walk) been wired to the isochronous
> fabric, while others are using the normal coherent fabric.
> 
> So when it comes to this statement:
> 
>  If either the SMMU or system cannot *fully* support IO-coherent
>  access to SMMU structures/queues/translations, this reads as 0.
> 
> The HW is "partially" IO-coherent, so COHACC is 0.
> 
> It has been lucky that so far the incorrect attributes haven't caused a
> problem, but the next spin of this HW may have issue here. I'd like to
> see it fixed.

I'm not against being more careful about the memory attributes used by
the non-coherent walker, but we shouldn't fool ourselves into thinking
that Linux can treat coherent devices as non-coherent and expect things
to work generally. The use of non-cacheable mappings in
dma_alloc_coherent() and cache invalidation in the streaming API when
transferring buffer ownership back to the CPU can both lead to DMA
corruption if the device can snoop the CPU caches.

I think we're all agreed on that, but just wanted to make sure as this
is something that has come up before when talking to hardware folks
who seem to think that the "dma-coherent" property is a hint.

Will


  reply	other threads:[~2026-01-20 12:14 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-12-29  0:23 [PATCH] iommu/arm-smmu-v3: Maintain valid access attributes for non-coherent SMMU Dawei Li
2026-01-02 18:41 ` Jason Gunthorpe
2026-01-04 13:35   ` Dawei Li
2026-01-05  0:02     ` Jason Gunthorpe
2026-01-05 13:33 ` Robin Murphy
2026-01-05 14:53   ` Jason Gunthorpe
2026-01-05 16:02     ` Robin Murphy
2026-01-05 18:54       ` Jason Gunthorpe
2026-01-20 12:14         ` Will Deacon [this message]
2026-01-20 13:11           ` Jason Gunthorpe
2026-01-05 15:46   ` Dawei Li

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=aW9xs1ko3nWq5VbS@willie-the-truck \
    --to=will@kernel.org \
    --cc=dawei.li@linux.dev \
    --cc=iommu@lists.linux.dev \
    --cc=jgg@ziepe.ca \
    --cc=joro@8bytes.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=robin.murphy@arm.com \
    --cc=set_pte_at@outlook.com \
    --cc=stable@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox