All of lore.kernel.org
 help / color / mirror / Atom feed
From: Mostafa Saleh <smostafa@google.com>
To: Pranjal Shrivastava <praan@google.com>
Cc: Jason Gunthorpe <jgg@nvidia.com>,
	Daniel Mentz <danielmentz@google.com>,
	iommu@lists.linux.dev, linux-kernel@vger.kernel.org,
	Will Deacon <will@kernel.org>, Liviu Dudau <liviu.dudau@arm.com>,
	Rob Clark <robin.clark@oss.qualcomm.com>
Subject: Re: [PATCH 2/2] drivers/arm-smmu-v3: Implement .iotlb_sync_map callback
Date: Tue, 30 Sep 2025 09:27:21 +0000	[thread overview]
Message-ID: <aNuieevIo9MuzBq2@google.com> (raw)
In-Reply-To: <aNsjFm56D8pnAKDp@google.com>

On Tue, Sep 30, 2025 at 12:23:50AM +0000, Pranjal Shrivastava wrote:
> On Mon, Sep 29, 2025 at 09:47:19AM -0300, Jason Gunthorpe wrote:
> > On Mon, Sep 29, 2025 at 12:24:28PM +0000, Mostafa Saleh wrote:
> > > On Mon, Sep 29, 2025 at 08:58:03AM -0300, Jason Gunthorpe wrote:
> > > > On Sat, Sep 27, 2025 at 10:39:53PM +0000, Daniel Mentz wrote:
> > > > > @@ -3700,6 +3713,7 @@ static const struct iommu_ops arm_smmu_ops = {
> > > > >  		.map_pages		= arm_smmu_map_pages,
> > > > >  		.unmap_pages		= arm_smmu_unmap_pages,
> > > > >  		.flush_iotlb_all	= arm_smmu_flush_iotlb_all,
> > > > > +		.iotlb_sync_map		= arm_smmu_iotlb_sync_map,
> > > > 
> > > > Shouldn't this avoid defining the op on coherent systems?
> > > 
> > > Does that mean we need to have 2 iommu_ops, one for
> > > coherent/non-coherent SMMUs, as both can be mixed in the same system.
> > 
> > Yes, I think you'd have to do it with two ops..
> > 
> > It just seems wrong to penalize the normal fast case for these
> > systems.
> > 
> 
> I see we plan to set defer_sync_pte = true always. What if we invoke the
> ops->iotlb_sync_map() only for incoherent IOMMUs? Maybe something like:
> 
> static int arm_smmu_iotlb_sync_map(struct iommu_domain *domain,
> 				    unsigned long iova, size_t size)
> {
> 	struct io_pgtable_ops *ops = to_smmu_domain(domain)->pgtbl_ops;
> 	struct arm_smmu_device *smmu = to_smmu_domain(domain)->smmu;
> 	bool is_coherent = smmu->features & ARM_SMMU_FEAT_COHERENCY;
> 
> 
> 	if (!ops || !ops->iotlb_sync_map || is_coherent)
> 		return 0;
> 
> 	ops->iotlb_sync_map(ops, iova, size);
> 	return 0;
> }
> 
> If needed we can push the coherency check to the io-pgtable op
> iotlb_sync_map() as well. Just an idea..
> 

iotlb_sync_map is already NULL for coherent SMMUs, I beleive
Jason's point is about that the iommu_ops.default_domain_ops
will have the extra pointer which will be called by the core code
anyway, which immediatly returns; wasting some cylces.
To avoid this we can have 2 sets of the default_domain_ops for
coherent and non-coherent devices, to be chosen at domain alloc time.

Though, It would be intersting to measure how much overhead does the
current approach have in practice, maybe through dma_map_benchmark?

Thanks,
Mostafa

> > Jason
> 
> Thanks,
> Praan

  reply	other threads:[~2025-09-30  9:27 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-09-27 22:39 [PATCH 1/2] iommu/io-pgtable-arm: Implement .iotlb_sync_map callback Daniel Mentz
2025-09-27 22:39 ` [PATCH 2/2] drivers/arm-smmu-v3: " Daniel Mentz
2025-09-29 11:58   ` Jason Gunthorpe
2025-09-29 12:24     ` Mostafa Saleh
2025-09-29 12:47       ` Jason Gunthorpe
2025-09-30  0:23         ` Pranjal Shrivastava
2025-09-30  9:27           ` Mostafa Saleh [this message]
2025-09-30 14:56             ` Pranjal Shrivastava
2025-09-29 12:25   ` Mostafa Saleh
2025-09-29 12:21 ` [PATCH 1/2] iommu/io-pgtable-arm: " Mostafa Saleh
2025-09-29 21:00   ` Daniel Mentz
2025-09-30  9:10     ` Mostafa Saleh
2025-11-04 13:28       ` Will Deacon
2025-11-04 13:37         ` Jason Gunthorpe
2025-09-29 19:57 ` Pranjal Shrivastava
2025-09-29 20:42   ` Daniel Mentz
2025-09-29 22:24     ` Pranjal Shrivastava

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=aNuieevIo9MuzBq2@google.com \
    --to=smostafa@google.com \
    --cc=danielmentz@google.com \
    --cc=iommu@lists.linux.dev \
    --cc=jgg@nvidia.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=liviu.dudau@arm.com \
    --cc=praan@google.com \
    --cc=robin.clark@oss.qualcomm.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.