Avi Kivity wrote: > 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 >
Let dmar_domains share io page table is not allowed. VT-d spec allows one domain corresponds to one page table, vice versa. If we want "something" owns the io page table, which shared by all assigned devices to one guest, we need to redefine dmar_domain which covers all devices assigned to a guest. Then we need to rewrite most of native VT-d code for kvm. Xen doesn't use dmar_domain, instead it implements "something" as a domain sturcture (with domain id) to own page table. One guest has only one "something" instance, thus has only one page table. It looks like: xen ---> something (owns io page table) ---> device. But, in KVM side, I think we can reuse native VT-d code, needn't to duplicate another VT-d code. Regards, Weidong > 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. -- 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
