On Tue, Jan 25, 2022 at 02:48:02PM +0000, Robin Murphy wrote:
Agreed, certainly an IOMMU_DOMAIN_SVA type that can both encapsulate the mm
and effectively replace iommu_sva seems like a logical and fairly small next
step. We already have the paradigm of different domain types supporting
different ops, so initially an SVA domain would simply allow bind/unbind
rather than attach/detach/map/unmap.
I hope we can quickly get to a PASID enabled generic attach/detach
scheme - we really need this to do the uAPI part of this interface.
they are fundamentally different things in their own right, and the ideal
API should give us the orthogonality to also bind a device to an SVA domain
without PASID (e.g. for KVM stage 2, or userspace assignment of simpler
fault/stall-tolerant devices), or attach PASIDs to regular iommu_domains.
Yes, these are orthogonal things. A iommu driver that supports PASID
ideally should support PASID enabled attach/detatch for every
iommu_domain type it supports.
SVA should not be entangled with PASID beyond that SVA is often used
with PASID - a SVA iommu_domain should be fully usable with a RID too.
I'm hoping to see the core iommu code provide some simplified "SVA"
API that under the covers creates a SVA domain and then does a normal
PASID attach using the global PASID in the mm_struct - the
driver should not care what, or even if, PASID is used for a SVA
domain.
Jason