> From: Tian, Kevin > Sent: Monday, November 26, 2018 11:01 AM [...] > > aux-domain is just a normal domain (struct iommu_domain), what > > happens > > when a domain that was used as a primary domain and has bound > > aux-domains to it, is bound with iommu_aux_domain_attach() to another > > domain? > > aux domain is essentially a way to lend partial DMA capability to less- > privileged entity (process or VM), which implies that part of DMA > unmanaged by kernel driver. If we can make such assumption that aux > only applies to UNMANAGED domain (thus disallow BLOCKED/IDENTITY/ > DMA from using aux), then above open doesn't exist, because if primary > domain is UNMANAGED type it essentially means the whole device fully > owned by user space or guest thus no host driver entity to ever create > aux domain. If primary domain is not UNMANAGED type, it will fail in > aux API. with this design, each device will have at most one primary > and multiple aux, i.e. just two layers. no aux-bind-to-aux thing. > > this assumption should be true in discussed usages around aux domain. > but I may overlook something... Jean? >
btw Baolu just reminded me one thing which is worthy of noting here. 'primary' vs. 'aux' concept makes sense only when we look from a device p.o.v. That binding relationship is not (*should not be*) carry-and-forwarded cross devices. every domain must be explicitly attached to other devices (instead of implicitly attached being above example), and new primary/aux attribute on another device will be decided at attach time. Thanks Kevin _______________________________________________ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
