From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jike Song Subject: Re: [PATCH v3 00/11] KVM: x86: track guest page access Date: Tue, 23 Feb 2016 11:02:25 +0800 Message-ID: <56CBCBC1.8050902@intel.com> References: <1455449503-20993-1-git-send-email-guangrong.xiao@linux.intel.com> <56C703C3.5070201@redhat.com> <56CADD6D.2040603@linux.intel.com> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: Paolo Bonzini , gleb@kernel.org, mtosatti@redhat.com, kvm@vger.kernel.org, linux-kernel@vger.kernel.org, kai.huang@linux.intel.com, Andrea Arcangeli , "Tian, Kevin" To: Xiao Guangrong Return-path: In-Reply-To: <56CADD6D.2040603@linux.intel.com> Sender: linux-kernel-owner@vger.kernel.org List-Id: kvm.vger.kernel.org +Kevin On 02/22/2016 06:05 PM, Xiao Guangrong wrote: > > On 02/19/2016 08:00 PM, Paolo Bonzini wrote: >> >> I still have a doubt: how are you going to handle invalidation of GPU >> shadow page tables if a device (emulated in QEMU or even vhost) does DMA >> to the PPGTT? > > I think Jike is the better one to answer this question, Jike, could you > please clarify it? :) > Sure :) Actually in guest PPGTT is manipulated by CPU rather than GPU. The PPGTT page table itself are plain memory, composed & modified by the GPU driver, i.e. by CPU in Non-Root mode. Given that, we write-protected guest PPGTT, when VM writes PPGTT, EPT violation rather than DMA fault happens. >> Generally, this was the reason to keep stuff out of KVM >> and instead hook into the kernel mm subsystem (as with userfaultfd). > > We considered it carefully but this way can not satisfy KVMGT's requirements. > The reasons i explained in the old thread (https://lkml.org/lkml/2015/12/1/516) > are: > > "For the performance, shadow GPU is performance critical and requires > frequently being switched, it is not good to handle it in userspace. And > windows guest has many GPU tables and updates it frequently, that means, > we need to write protect huge number of pages which are single page based, > I am afraid userfaultfd can not handle this case efficiently. > > For the functionality, userfaultfd can not fill the need of shadow page > because: > - the page is keeping readonly, userfaultfd can not fix the fault and let > the vcpu progress (write access causes writeable gup). > > - the access need to be emulated, however, userfaultfd/kernel does not have > the ability to emulate the access as the access is trigged by guest, the > instruction info is stored in VMCS so that only KVM can emulate it. > > - shadow page needs to be notified after the emulation is finished as it > should know the new data written to the page to update its page hierarchy. > (some hardwares lack the 'retry' ability so the shadow page table need to > reflect the table in guest at any time). " > > Any idea? >