Re: [PATCH 01/10] nEPT: Module option

[Avi Kivity <avi@redhat.com>]

On 11/10/2011 04:21 PM, Nadav Har'El wrote:
> On Thu, Nov 10, 2011, Avi Kivity wrote about "Re: [PATCH 01/10] nEPT: Module option":
> > On 11/10/2011 11:58 AM, Nadav Har'El wrote:
> > > Add a module option "nested_ept" determining whether to enable Nested EPT.
> >...
> > > In the future, we can support emulation of EPT for L1 *always*, even when L0
> > > itself doesn't have EPT. This so-called "EPT on shadow page tables" mode
> > > has some theoretical advantages over the baseline "shadow page tables on
> > > shadow page tables" mode typically used when EPT is not available to L0 -
> > > namely that L2's cr3 changes and page faults can be handled in L0 and do not
> > > need to be propagated to L1. However, currently we do not support this mode,
> > > and it is becoming less interesting as newer processors all support EPT.
> > >
> > >
> > 
> > I think we can live without this.
>
> By "this", do you mean without the "nested_ept" option, or without the
> hypothetical "EPT on shadow page tables" feature?

Er, both.  The feature should be controlled on a per-guest basis, not
per host.  And while emulating EPT on shadow is possible, we have enough
complexity already, I think, and non-EPT hosts are getting rarer.

> If the former, then I agree we can "live" without it, but since it was
> trivial to add, I don't see what harm it can do, and its nice that we
> can return with a single L0 option to the old shadow-on-ept paging.
> Is there anything specific you don't like about having this option?

It's just redundant, since we do need a per-guest control.

> About the latter, I agree - as I said, there isn't much point to go and
> write this (quite complicated) 3-level shadowing when all new processors
> have EPT anyway. So I didn't.
>
> > But we do need a way to control what
> > features are exposed to the guest, for compatibility and live migration
> > purposes, as we do with cpuid.  So we need some way for host userspace
> > to write to the vmx read-only feature reporting MSRs.
>
> I think this is a general issue (which we already discussed earlier),
> of nested VMX and not specific to nested EPT. I already put all the
> capabilities which the MSR report in variables initialized in a single
> function, nested_vmx_setup_ctls_msrs(), so once we devise an appropriate
> userspace interface to set these, we can do so easily.

Yes.

> Does nested SVM also have a similar problem, of whether or not it
> advertises new or optional SVM features to L1? If it does have this
> problem, how was it solved there?

svm cpu features are, funnily enough, reported by cpuid, so the existing
KVM_GET_SUPPORTED_CPUID/KVM_SET_CPUID2 method works.  We need a similar
KVM_SET_READONLY_MSRS or something.

-- 
error compiling committee.c: too many arguments to function