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. > 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
