All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jason Gunthorpe <jgg@nvidia.com>
To: Peter Zijlstra <peterz@infradead.org>
Cc: Nicolin Chen <nicolinc@nvidia.com>,
	will@kernel.org, jean-philippe@linaro.org, robin.murphy@arm.com,
	joro@8bytes.org, balbirs@nvidia.com, miko.lenczewski@arm.com,
	kevin.tian@intel.com, praan@google.com,
	linux-arm-kernel@lists.infradead.org, iommu@lists.linux.dev,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH v7 6/7] iommu/arm-smmu-v3: Add arm_smmu_invs based arm_smmu_domain_inv_range()
Date: Tue, 16 Dec 2025 10:15:11 -0400	[thread overview]
Message-ID: <20251216141511.GD6079@nvidia.com> (raw)
In-Reply-To: <20251216140410.GV3707837@noisy.programming.kicks-ass.net>

On Tue, Dec 16, 2025 at 03:04:10PM +0100, Peter Zijlstra wrote:
> On Tue, Dec 16, 2025 at 09:56:13AM -0400, Jason Gunthorpe wrote:
> > On Tue, Dec 16, 2025 at 10:09:26AM +0100, Peter Zijlstra wrote:
> > > Anyway, if I understand the above correctly, the smb_mb() is for:
> > > 
> > >   arm_smmu_domain_inv_range() 		arm_smmu_install_new_domain_invs()
> > > 
> > >     [W] IOPTE				  [Wrel] smmu_domain->invs
> > >     smp_mb()				  smp_mb()
> > >     [Lacq] smmu_domain->invs		  [L] IOPTE
> > > 
> > > Right? But I'm not sure about your 'HW sees the new IOPTEs' claim;
> > 
> > Yes, the '[L] IOPTE' would be a DMA from HW.
> > 
> > > that very much depend on what coherency domain the relevant hardware
> > > plays in. For smp_mb() to work, the hardware must be in the ISH
> > > domain, while typically devices are (if I remember my arrrrgh64
> > > correctly) in the OSH.
> > 
> > The '[W] IOPTE' sequence already includes a cache flush if the
> > inner/outer sharable are not coherent. If a cache flush was required
> > then the smp_mb() must also order it, otherwise it just has to order
> > the store.
> > 
> > The page table table code has always relied on this kind of ordering
> > with respect to DMA working, it would be completely broken if the DMA
> > does not order with the barriers.
> > 
> > For example:
> > 
> >             CPU0                         CPU1
> >    store PMD
> >                                         read PMD
> >    store PTE 1                          store PTE 2
> >    	     				dma memory barrier
> >                                         device reads 2
> >    dma memory barrier
> >    device reads 1
> 
> But here you have dma_mb(), which is dmb(osh).

This also has a pre-existing dma_wmb(), a fuller chart would be like this:

   arm_smmu_domain_inv_range() 		arm_smmu_install_new_domain_invs()
 
     [W] IOPTE				  [Wrel] smmu_domain->invs
     smp_mb()				  smp_mb()  <--- arm_smmu_install_new_domain_invs()
					  [build the STE]
					  [post the STE]
					  dma_wmb() <--- arm_smmu_cmdq_issue_cmdlist()
                                          Doorbell Write to Device
     [Lacq] smmu_domain->invs		  [L] IOPTE via DMA

Nicolin, please elabortate more of these details in the comment.

Jason


  reply	other threads:[~2025-12-16 14:15 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-12-16  2:09 [PATCH v7 0/7] iommu/arm-smmu-v3: Introduce an RCU-protected invalidation array Nicolin Chen
2025-12-16  2:09 ` [PATCH v7 1/7] iommu/arm-smmu-v3: Explicitly set smmu_domain->stage for SVA Nicolin Chen
2025-12-16  2:09 ` [PATCH v7 2/7] iommu/arm-smmu-v3: Add an inline arm_smmu_domain_free() Nicolin Chen
2025-12-16  2:09 ` [PATCH v7 3/7] iommu/arm-smmu-v3: Introduce a per-domain arm_smmu_invs array Nicolin Chen
2025-12-16  2:09 ` [PATCH v7 4/7] iommu/arm-smmu-v3: Pre-allocate a per-master invalidation array Nicolin Chen
2025-12-16  2:09 ` [PATCH v7 5/7] iommu/arm-smmu-v3: Populate smmu_domain->invs when attaching masters Nicolin Chen
2025-12-16  2:09 ` [PATCH v7 6/7] iommu/arm-smmu-v3: Add arm_smmu_invs based arm_smmu_domain_inv_range() Nicolin Chen
2025-12-16  9:09   ` Peter Zijlstra
2025-12-16 13:56     ` Jason Gunthorpe
2025-12-16 14:04       ` Peter Zijlstra
2025-12-16 14:15         ` Jason Gunthorpe [this message]
2025-12-16 19:14           ` Nicolin Chen
2025-12-16  2:09 ` [PATCH v7 7/7] iommu/arm-smmu-v3: Perform per-domain invalidations using arm_smmu_invs Nicolin Chen

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=20251216141511.GD6079@nvidia.com \
    --to=jgg@nvidia.com \
    --cc=balbirs@nvidia.com \
    --cc=iommu@lists.linux.dev \
    --cc=jean-philippe@linaro.org \
    --cc=joro@8bytes.org \
    --cc=kevin.tian@intel.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=miko.lenczewski@arm.com \
    --cc=nicolinc@nvidia.com \
    --cc=peterz@infradead.org \
    --cc=praan@google.com \
    --cc=robin.murphy@arm.com \
    --cc=will@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.