From mboxrd@z Thu Jan 1 00:00:00 1970 From: Avi Kivity Subject: Re: [PATCH 08/10] nEPT: Nested INVEPT Date: Sun, 11 Dec 2011 16:37:52 +0200 Message-ID: <4EE4C040.1070504@redhat.com> References: <1320919040-nyh@il.ibm.com> <201111101001.pAAA1vqV019702@rice.haifa.ibm.com> <4EBBC0F2.8040002@redhat.com> <20111211142454.GA9179@fermat.math.technion.ac.il> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: kvm@vger.kernel.org, "Roedel, Joerg" , owasserm@redhat.com, abelg@il.ibm.com To: "Nadav Har'El" Return-path: Received: from mx1.redhat.com ([209.132.183.28]:27030 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751914Ab1LKOiD (ORCPT ); Sun, 11 Dec 2011 09:38:03 -0500 In-Reply-To: <20111211142454.GA9179@fermat.math.technion.ac.il> Sender: kvm-owner@vger.kernel.org List-ID: On 12/11/2011 04:24 PM, Nadav Har'El wrote: > On Thu, Nov 10, 2011, Avi Kivity wrote about "Re: [PATCH 08/10] nEPT: Nested INVEPT": > > On 11/10/2011 12:01 PM, Nadav Har'El wrote: > > > If we let L1 use EPT, we should probably also support the INVEPT instruction. > >.. > > > + if (vmcs12 && nested_cpu_has_ept(vmcs12) && > > > + (vmcs12->ept_pointer == operand.eptp) && > > > + vmx->nested.last_eptp02) > > > + ept_sync_context(vmx->nested.last_eptp02); > > > + else > > > + ept_sync_global(); > > > > Are either of these needed? Won't a write to a shadowed EPT table cause > > them anyway? > > This is very good point... You're right that as it stands, any changes > to the guest EPT table (EPT12) will cause changes to the shadow EPT > table (EPT02), and these already cause KVM to do an INVEPT, so no point > to do this again when the guest asks. So basically, I can have INVEPT > emulated by doing absolutely nothing (after checking all the checks), right? Right. This was the case for INVLPG before we added out-of-sync pages; we didn't even intercept the instruction. > I wonder if I am missing any reason why a hypervisor might want to do > INVEPT without changing the EPT12 table first. Shouldn't happen, but why do you care? If EPT12 has not changed, any access through EPT02 or its TLB entry is valid. -- error compiling committee.c: too many arguments to function