Han, Weidong wrote: >> >> There is a missed optimization here. Suppose we have two devices each >> under a different iommu. With the patch, each will be in a different >> dmar_domain and so will have a different page table. The amount of >> memory used is doubled. >> > > You cannot let two devices each under a different iommu share one > dmar_domain, becasue dmar_domain has a pointer to iommu. > >
I don't want then to share dmar_domains (these are implementation details anyway), just io page tables. kvm ---> something (owns io page table) ---> dmar_domain (uses shared io page table) ---> device Even if we don't implement io page table sharing right away, implementing the 'something' in the iommu api means we can later impement sharing without changing the iommu/kvm interface. > In fact, the exported APIs added for KVM VT-d also do > create/map/attach/detach/free functions. Whereas these iommu APIs are > more readable. > > No; the existing iommu API talks about dmar domains and exposes the existence of multiple iommus, so it is more complex. > Because kvm VT-d usage is different with native usage, it's inevitable > extend native VT-d code to support KVM VT-d (such as wrap dmar_domain). > For devices under different iommus, they cannot share the same > dmar_domain, thus they cannot share VT-d page table. If we want to > handle this by iommu APIs, I suspect we need to change lots of native > VT-d driver code. > As mentioned above, we can start with implementing the API without actual sharing (basically, your patch, but as an addition to the API rather than a change to kvm); we can add io pagetable sharing later. -- Do not meddle in the internals of kernels, for they are subtle and quick to panic. -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
