On Mon, Jul 29, 2013 at 11:21:38AM +0200, Paolo Bonzini wrote:
> Il 25/07/2013 12:59, Gleb Natapov ha scritto:
> > + if (enable_ept) {
> > + /* nested EPT: emulate EPT also to L1 */
> > + nested_vmx_secondary_ctls_high |= SECONDARY_EXEC_ENABLE_EPT;
> > + nested_vmx_ept_caps = VMX_EPT_PAGE_WALK_4_BIT;
> > + nested_vmx_ept_caps |=
> > + VMX_EPT_INVEPT_BIT | VMX_EPT_EXTENT_GLOBAL_BIT |
> > + VMX_EPT_EXTENT_CONTEXT_BIT |
> > + VMX_EPT_EXTENT_INDIVIDUAL_BIT;
>
> What version of the Intel manual defines bit 24? Mine is January 2013
> and only has 20/25/26.
>
Good question. Looks like this crept in while Jun rebased Nadavs patch
on more resent master. This bit was defined by initial EPT implementation,
but was dropped by commit 2b3c5cbc0d814437fe4d70cc11ed60550b95b29f not
long time ago.
> > + nested_vmx_ept_caps &= vmx_capability.ept;
>
> This is always missing VMX_EPT_EXECUTE_ONLY_BIT, should it be added
> before the "&=".
I am not at all sure our current shadow implementation can support
execute only pages. Best to leave it off for now.
>
> Also, the three extent bits should always be fine for the MSR,
> independent of the host support, because the processor will do the
> INVEPT vmexit before checking the INVEPT type against the processor
> capabilities. So they can be added after the "&=".
>
Good point.
> Related to this, I suppose enable_ept should depend on
> VMX_EPT_INVEPT_BIT too (it currently doesn't) since vmx_flush_tlb does
> an unconditional invept under "if (enable_ept)". This is really just
> nitpicking though.
>
> Paolo
>
> > + } else
> > + nested_vmx_ept_caps = 0;
--
Gleb.
--
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
