From mboxrd@z Thu Jan 1 00:00:00 1970 From: Avi Kivity Subject: Re: [PATCH] [RESEND] VT-d: Support multiple device assignment to one guest Date: Thu, 09 Oct 2008 10:31:03 +0200 Message-ID: <48EDC147.4080907@redhat.com> References: <0122C7C995D32147B66BF4F440D3016301CF9679@pdsmsx415.ccr.corp.intel.com> <48EB6431.4070300@redhat.com> <0122C7C995D32147B66BF4F440D3016301D2955D@pdsmsx415.ccr.corp.intel.com> <48EC8C2C.5070801@redhat.com> <0122C7C995D32147B66BF4F440D3016301D2998F@pdsmsx415.ccr.corp.intel.com> <48ED0ED1.6040308@redhat.com> <0122C7C995D32147B66BF4F440D3016301D555B3@pdsmsx415.ccr.corp.intel.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Joerg Roedel , kvm@vger.kernel.org, Amit Shah , "Kay, Allen M" , "Yang, Sheng" , benami@il.ibm.com, muli@il.ibm.com, "Woodhouse, David" , "Barnes, Jesse" To: "Han, Weidong" Return-path: Received: from mx2.redhat.com ([66.187.237.31]:45858 "EHLO mx2.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751490AbYJIIdn (ORCPT ); Thu, 9 Oct 2008 04:33:43 -0400 In-Reply-To: <0122C7C995D32147B66BF4F440D3016301D555B3@pdsmsx415.ccr.corp.intel.com> Sender: kvm-owner@vger.kernel.org List-ID: 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.