From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jike Song Subject: Re: [Qemu-devel] [iGVT-g] RE: VFIO based vGPU(was Re: [Announcement] 2015-Q3 release of XenGT - a Mediated ...) Date: Thu, 04 Feb 2016 23:04:35 +0800 Message-ID: <56B36883.20205@intel.com> References: <1454532287.18969.14.camel@redhat.com> <20160204035222.GA7092@nvidia.com> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: Neo Jia , Yang Zhang , "igvt-g@lists.01.org" , "kvm@vger.kernel.org" , qemu-devel , Kirti Wankhede , Alex Williamson , "Lv, Zhiyuan" , Paolo Bonzini , Gerd Hoffmann To: "Tian, Kevin" Return-path: Received: from mga09.intel.com ([134.134.136.24]:54135 "EHLO mga09.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S965819AbcBDPFh (ORCPT ); Thu, 4 Feb 2016 10:05:37 -0500 In-Reply-To: Sender: kvm-owner@vger.kernel.org List-ID: 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