On Mon, Apr 20, 2020 at 09:42:13AM +0200, Jean-Philippe Brucker wrote: > On Thu, Apr 16, 2020 at 05:13:31AM -0700, Christoph Hellwig wrote: > > On Thu, Apr 16, 2020 at 10:54:02AM +0200, Jean-Philippe Brucker wrote: > > > On Thu, Apr 16, 2020 at 12:28:52AM -0700, Christoph Hellwig wrote: > > > > > + rcu_read_lock(); > > > > > + hlist_for_each_entry_rcu(bond, &io_mm->devices, mm_node) > > > > > + io_mm->ops->invalidate(bond->sva.dev, io_mm->pasid, io_mm->ctx, > > > > > + start, end - start); > > > > > + rcu_read_unlock(); > > > > > +} > > > > > > > > What is the reason that the devices don't register their own notifiers? > > > > This kinds of multiplexing is always rather messy, and you do it for > > > > all the methods. > > > > > > This sends TLB and ATC invalidations through the IOMMU, it doesn't go > > > through device drivers > > > > I don't think we mean the same thing, probably because of my rather > > imprecise use of the word device. > > > > What I mean is that the mmu_notifier should not be embedded into the > > io_mm structure (whch btw, seems to have a way to generic name, just > > like all other io_* prefixed names), but instead into the > > iommu_bond structure. That avoid the whole multiplexing layer. > > Right, I can see the appeal. I still like having a single mmu notifier per > mm because it ensures we allocate a single PASID per mm (as required by > x86). I suppose one alternative is to maintain a hashtable of mm->pasid, > to avoid iterating over all bonds during allocation. I've been getting rid of hash tables like this.. Adding it to the mm_struct does seem reasonable, I think PASID is a pretty broad concept now. Jason
