Han, Weidong wrote: > Avi Kivity wrote: >> Han, Weidong wrote: >>>> >>>> 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. >> >> Since the io pagetables are read only for the iommu (right?), I don't >> see what prevents several iommus from accessing the same pagetable. >> It's just a bunch of memory. > > I think the reason is that hardware may use the domain identifier to > tag its internal caches. > >> >>> 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. >> >> I imagine, Xen shares the io pagetables with the EPT pagetables as >> well. So io pagetable sharing is allowed. > > In Xen, VT-d page table doesn't share with EPT pagetable and P2M > pagetable. But they can share if the format is the same. > >> >>> 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. >>> >> >> I agree that at this stage, we don't want to do optimization, we need >> something working first. But let's at least ensure the API allows >> the optimization later on (and also, that iommu implementation >> details are hidden from kvm). >> >> What I'm proposing is moving the list of kvm_vtd_domains inside the >> iommu API. The only missing piece is populating a new dmar_domain >> when a new device is added. We already have > > I will move kvm_vtd_domain inside the iommu API, and also hide > get_kvm_vtd_domain() and release_kvm_vtd_domain() implementation > details from kvm.
It's hard to move kvm_vtd_domain inside current iommu API. It's kvm specific. It's not elegant to include kvm_vtd_domain stuffs in native VT-d code. I think leave it in kvm side is more clean at this point. Moveover it's very simple. I read Joerg's iommu API foils just now, I think it's good. Native AMD iommu code will be in 2.6.28, it's a suitable to implement a generic iommu API based both on Intel and AMD iommu for kvm after 2.6.28. What's your opinion? Regards, Weidong > >> intel_iommu_iova_to_pfn(), we need to add a way to read the >> protection bits and the highest mapped iova (oh, and >> intel_iommu_iova_to_pfn() has a bug: it shifts right instead of >> left). >> > > Why do we need the protection bits and the highest mapped iova? > > Shifting right instead of left in intel_iommu_iova_to_pfn() is not a > bug, because it returns pfn, not address. > > Regards, > Weidong > >> Later we can make the "something" (that already contains the list) >> also own the io page table; and non-kvm users can still use the same >> code (the list will always be of length 1 for these users). -- 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
