Messages in this thread | | | Date | Wed, 11 May 2022 09:02:40 -0300 | From | Jason Gunthorpe <> | Subject | Re: [PATCH v6 03/12] iommu: Add attach/detach_dev_pasid domain ops |
| |
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.
Jason
| |