Re: [PATCH v6 17/25] iommu/arm-smmu-v3: Implement iommu_sva_bind/unbind()

Jean-Philippe Brucker
2020-05-04T16:07:47Z

On Fri, May 01, 2020 at 09:55:13AM -0300, Jason Gunthorpe wrote:
> On Fri, May 01, 2020 at 05:15:52AM -0700, Christoph Hellwig wrote:
> > > @@ -432,6 +432,7 @@ config ARM_SMMU_V3
> > > tristate "ARM Ltd. System MMU Version 3 (SMMUv3) Support"
> > > depends on ARM64
> > > select IOMMU_API
> > > + select IOMMU_SVA
> > > select IOMMU_IO_PGTABLE_LPAE
> > > select GENERIC_MSI_IRQ_DOMAIN
> >
> > Doesn't this need to select MMU_NOTIFIER now?
> >
> > > + struct mmu_notifier_ops mn_ops;
> >
> > Note: not a pointer.
> >
> > > + /* If bind() was already called for this (dev, mm) pair, reuse it. */
> > > + list_for_each_entry(bond, &master->bonds, list) {
> > > + if (bond->mm == mm) {
> > > + refcount_inc(&bond->refs);
> > > + return &bond->sva;
> > > + }
> > > + }
>
> I also would like it if searching for mms in linked lists was not
> necessary, this is kind of the point of 'get'
>
> Is this a side effect of the earlier remark to get rid of the linked
> list inside the notifier?
>
> > Or we could enhance the mmu_notifier_get to pass a private
> > oaque instance ID pointer, which is checked in addition to the ops,
> > and you could probably kill off the bonds list and lookup.
>
> This might be the best option if it can absorb the above search..

It wouldn't, the above search is separate. I currently register the MMU
notifier on (IOMMU domain, mm). The (dev, mm) search above is to follow
the iommu_sva_bind_device() API doc, that states we should return the same
handle for a given (dev, mm) pair.

Thanks,
Jean