> From: Tian, Kevin > Sent: Thursday, July 26, 2018 11:04 AM [...] > > > > The IOMMU operations we care about don't take a device handle, I think, > > just a domain. And VFIO itself only deals with domains when doing > > map/unmap. Maybe we could add this operation to the IOMMU > subsystem: > > > > child_domain = domain_create_child(parent_dev, parent_domain) > > > > A child domain would be a smaller isolation granule, getting a PASID if > > that's what the IOMMU implements or another mechanism for 2). It is > > automatically attached to its parent's devices, so attach/detach > > operations wouldn't be necessary on the child. > > > > Depending on the underlying architecture the child domain can support > > map/unmap on a single stage, or map/unmap for 2nd level and > > bind_pgtable > > for 1st level. > > > > I'm not sure how this works for host SVA though. I think the > > sva_bind_dev() API could stay the same, but the internals will need > > to change. > > > > hierarchical domain might be the right way to go, but let's do more > thinking on any corner cases. > btw maybe we don't need make it 'hierarchical', as maintaining hierarchy usually brings more work. What we require is possibly just the capability of having one device bind to multiple iommu_domains. One domain is reserved for parent driver's own DMA activities (e.g. serving DMA APIs), while other domains are auxiliary and can be tagged with a PASID (or any other identifier which IOMMU can use to support multiple domains). Such identifiers may be automatically provisioned when auxiliary domain is attached, i.e. not requiring an explicit request from caller. IMO it's safe to assume that supporting multiple iommu domains anyway implies some finer-grained capability than RID-based in underlying IOMMU. Then there is no need of parent/child concept. thoughts? Thanks Kevin
