Messages in this thread | | | Date | Thu, 12 May 2022 08:00:59 +0100 | From | Jean-Philippe Brucker <> | Subject | Re: [PATCH v6 03/12] iommu: Add attach/detach_dev_pasid domain ops |
| |
On Wed, May 11, 2022 at 09:02:40AM -0300, Jason Gunthorpe wrote: > On Wed, May 11, 2022 at 08:54:39AM +0100, Jean-Philippe Brucker wrote: > > > > > Then 'detach pasid' is: > > > > > > > > > > iommu_ops->blocking_domain->ops->attach_dev_pasid(domain, dev, > > > > pasid); > > > > > > > > > > And we move away from the notion of 'detach' and in the direction that > > > > > everything continuously has a domain set. PASID would logically > > > > > default to blocking_domain, though we wouldn't track this anywhere. > > > > > > > > I am not sure whether we still need to keep the blocking domain concept > > > > when we are entering the new PASID world. Please allow me to wait and > > > > listen to more opinions. > > > > > > > > > > I'm with Jason on this direction. In concept after a PASID is detached it's > > > essentially blocked. Implementation-wise it doesn't prevent the iommu > > > driver from marking the PASID entry as non-present as doing in this > > > series instead of actually pointing to the empty page table of the block > > > domain. But api-wise it does make the entire semantics more consistent. > > > > This is all internal to IOMMU so I don't think we should be concerned > > about API consistency. I prefer a straighforward detach() operation > > because that way IOMMU drivers don't have to keep track of which domain is > > attached to which PASID. That code can be factored into the IOMMU core. > > Why would a driver need to keep additional tracking? > > > In addition to clearing contexts, detach() also needs to invalidate TLBs, > > and for that the SMMU driver needs to know the old ASID (!= PASID) that > > was used by the context descriptor. We can certainly work around a missing > > detach() to implement this, but it will be convoluted. > > It is not "missing" it is just renamed to blocking_domain->ops->set_dev_pasid() > > The implementation of that function would be identical to > detach_dev_pasid.
attach(dev, pasid, sva_domain) detach(dev, pasid, sva_domain)
versus
set_dev_pasid(dev, pasid, sva_domain) set_dev_pasid(dev, pasid, blocking)
we loose the information of the domain previously attached, and the SMMU driver has to retrieve it to find the ASID corresponding to the mm.
Thanks, Jean
| |