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