On Fri, Aug 19, 2016 at 3:21 AM, Paolo Bonzini <pbonzini@xxxxxxxxxx> wrote: > > > On 18/08/2016 20:00, Jim Mattson wrote: >> If L0 sets the VMX_EPT_AD_ENABLE_BIT in the vmcs02 EPT pointer, then >> any TLB miss encountered while executing L2 will result in an EPT >> violation when the CPU tries to walk L2's page tables (write access to >> a write protected page). However, this EPT violation cannot be >> forwarded to L1, because L1's virtual CPU would not have delivered it. >> (L1's virtual CPU would have performed a read access rather than a >> write access.) >> >> With this configuration, L0 will have to emulate each and every L2 instruction. >> >> Better would be for L0 to set the VMX_EPT_AD_ENABLE_BIT in vmcs02 to >> match the VMX_EPT_AD_ENABLE_BIT in vmcs12. > > And in fact, because we don't expose the feature at all, vmcs02 should > never set the bit. Without exposing the feature, setting the bit should result in a VM-entry failure (per section 26.2.1.1 of the Intel SDM, volume 3), but I don't see any checks on the vmcs12 ept_pointer field. > > Would this fix a failure in kvm-unit-tests x86/vmx.c, too? Possibly. Which failure? > >> Of course, this means that L0 will lose the ability to do >> accessed/dirty page tracking of L2 using the shadow EPT tables for L2. > > Indeed, and that's the reason why I never got the courage to look into a > fix for that vmx.c failure... But maybe it would be enough to ensure > the A/D bits are set when FNAME(sync_page) calls set_spte (accessed is > set if speculative==false; for dirty you'd have to invent a new argument > or something like that). Dirty should probably be set any time that the shadow EPT entry has write permission. Then, we would only want to set write permission in the shadow EPT entry if the L0 and L1 EPT entries are writable *and* the current access is a write. -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
