Re: [PATCH 08/10] nEPT: Nested INVEPT

[Avi Kivity <avi@redhat.com>]

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