On 26/07/18 04:28, Tian, Kevin wrote: >> 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. Right, we probably don't need a hierarchy. I like this model (it's actually the one I favor for supporting PASID in virtio-iommu), though I'm hoping we can avoid changing the logic of iommu_attach/detach, and instead introduce a new "get_child_domain", "attach_aux_domain" or simply "clone" op. Currently the attach_dev() op toggles the domain of a device. For example a device automatically gets a default domain for kernel DMA, then VFIO attaches a new domain for assigning to a VM. attach_dev() disables the default domain and installs fresh page tables. detach_dev() isn't called, and the SMMU drivers don't even implement it. If we wanted to reuse attach_dev() for auxiliary domains, we'd need some flag to differentiate the "add auxiliary domain" operation from the "detach everything and attach one new domain" one Thanks, Jean
