From mboxrd@z Thu Jan 1 00:00:00 1970 From: Nadav Har'El Subject: Re: [PATCH 01/10] nEPT: Module option Date: Thu, 10 Nov 2011 16:21:15 +0200 Message-ID: <20111110142115.GA3327@fermat.math.technion.ac.il> References: <1320919040-nyh@il.ibm.com> <201111100958.pAA9wMeL019600@rice.haifa.ibm.com> <4EBBC22D.8090409@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: kvm@vger.kernel.org, "Roedel, Joerg" , owasserm@redhat.com, abelg@il.ibm.com To: Avi Kivity Return-path: Received: from mailgw12.technion.ac.il ([132.68.225.12]:45817 "EHLO mailgw12.technion.ac.il" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1756603Ab1KJO2p (ORCPT ); Thu, 10 Nov 2011 09:28:45 -0500 Content-Disposition: inline In-Reply-To: <4EBBC22D.8090409@redhat.com> Sender: kvm-owner@vger.kernel.org List-ID: 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? 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? 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. 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? -- Nadav Har'El | Thursday, Nov 10 2011, nyh@math.technion.ac.il |----------------------------------------- Phone +972-523-790466, ICQ 13349191 |I considered atheism but there weren't http://nadav.harel.org.il |enough holidays.