On Mon, May 01, 2017 at 02:58:22PM +1000, David Gibson wrote: > On Thu, Apr 27, 2017 at 05:34:18PM +0800, Peter Xu wrote: > > This is something similar to MemoryRegionOps, it's just for address > > spaces to store arch-specific hooks. > > > > The first hook I would like to introduce is iommu_get(). > > > > For systems that have IOMMUs, we will create a special address space per > > device which is different from system default address space for > > it (please refer to pci_device_iommu_address_space()). Normally when > > that happens, there will be one specific IOMMU (or say, translation > > unit) stands right behind that new address space. > > > > This iommu_get() fetches that guy behind the address space. Here, the > > guy is defined as IOMMUObject, which is currently a (void *). In the > > future, maybe we can make it a better definition, but imho it's good > > enough for now, considering it's arch-dependent. > > > > Signed-off-by: Peter Xu <pet...@redhat.com> > > This doesn't make sense to me. It would be entirely possible for a > single address space to have different regions mapped by different > IOMMUs. Or some regions mapped by IOMMUs and others direct mapped to > a device or memory block.
Oh, so it's more complicated than I thought... Then, do we really have existing use case that one device is managed by more than one IOMMU (on any of the platform)? Frankly speaking I haven't thought about complicated scenarios like this, or nested IOMMUs yet. This patch derived from a requirement in virt-svm project (on x86). Virt-svm needs some notification mechanism for each IOMMU (or say, the IOMMU that managers the SVM-enabled device). For now, all IOMMU notifiers are per-memory-region not per-iommu, and that's imho not what virt-svm wants. Any suggestions? Thanks, -- Peter Xu