From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:42561) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aRLTk-0007tk-Bi for qemu-devel@nongnu.org; Thu, 04 Feb 2016 10:05:57 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aRLTg-0004EF-U2 for qemu-devel@nongnu.org; Thu, 04 Feb 2016 10:05:52 -0500 Received: from mga02.intel.com ([134.134.136.20]:50230) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aRLTg-0004E3-8o for qemu-devel@nongnu.org; Thu, 04 Feb 2016 10:05:48 -0500 Message-ID: <56B36883.20205@intel.com> Date: Thu, 04 Feb 2016 23:04:35 +0800 From: Jike Song MIME-Version: 1.0 References: <1454532287.18969.14.camel@redhat.com> <20160204035222.GA7092@nvidia.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [iGVT-g] RE: VFIO based vGPU(was Re: [Announcement] 2015-Q3 release of XenGT - a Mediated ...) List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: "Tian, Kevin" Cc: Yang Zhang , "igvt-g@lists.01.org" , Neo Jia , "kvm@vger.kernel.org" , qemu-devel , Kirti Wankhede , Alex Williamson , "Lv, Zhiyuan" , Paolo Bonzini , Gerd Hoffmann On 02/04/2016 12:16 PM, Tian, Kevin wrote: >>>>> 5) Pin/unpin guest memory >>>>> -- >>>>> IGD or any PCI passthru should have same requirement. So we should be >>>>> able to leverage existing code in VFIO. The only tricky thing (Jike may >>>>> elaborate after he is back), is that KVMGT requires to pin EPT entry too, >>>>> which requires some further change in KVM side. But I'm not sure whether >>>>> it still holds true after some design changes made in this thread. So I'll >>>>> leave to Jike to further comment. >>>> >>>> PCI assignment requires pinning all of guest memory, I would think that >>>> IGD would only need to pin selective memory, so is this simply stating >>>> that both have the need to pin memory, not that they'll do it to the >>>> same extent? >>> >>> For simplicity let's first pin all memory, while taking selective pinning as a >>> future enhancement. >>> >>> The tricky thing is that existing 'pin' action in VFIO doesn't actually pin >>> EPT entry too (only pin host page tables for Qemu process). There are >>> various places where EPT entries might be invalidated when guest is >>> running, while KVMGT requires EPT entries to be pinned too. Let's wait >>> for Jike to elaborate whether this part is still required today. >> >> Sorry, don't quite follow the logic here. The current VFIO TYPE1 IOMMU (including API >> and underlying IOMMU implementation) will pin the guest physical memory and >> install those pages to the proper device domain. Yes, it is only for the QEMU >> process as that is what the VM is running at. >> >> Do I miss something here? > > For Qemu there are two page tables involved: one is host page table as > you mentioned here for root mode, the other is EPT page table used > as the 2nd level translation when guest is running in non-root mode. I'm > not sure why KVMGT requires to pin EPT entry. Jike should know better > here. > There may be some misunderstanding here - KVMGT doesn't need to pin EPT entries. Previously I mentioned spte pinning, only because that, at that time we wanted to query pfn for a given gfn by KVM MMU (rmap + spte). Now we have better way of this. I promise this is not a problem :) -- Thanks, Jike