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 -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
