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 -- 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
