From mboxrd@z Thu Jan 1 00:00:00 1970 From: Keir Fraser Subject: Re: EFER in HVM guests Date: Wed, 29 Nov 2006 17:21:50 +0000 Message-ID: References: <8FFF7E42E93CC646B632AB40643802A80184FF9F@scsmsx412.amr.corp.intel.com> Mime-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <8FFF7E42E93CC646B632AB40643802A80184FF9F@scsmsx412.amr.corp.intel.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: "Nakajima, Jun" , Jan Beulich , xen-devel@lists.xensource.com, Keir Fraser List-Id: xen-devel@lists.xenproject.org *Please* can you make the handling of generic CPUID leaves and architectural MSRs common HVM code? There is lots of needless code duplication right now with niggling differences that shouldn't be necessary. -- Keir On 29/11/06 16:34, "Nakajima, Jun" wrote: >> I think it does - allowing a guest to enable EFER.LME when the >> hypervisor is a 32-bit one is clearly a security problem: While I >> haven't tried it, I would suspect the moment you load a context >> with such an EFER the whole system's dead. >> Not being able to access EFER is also a potential problem, as a >> guest should be allowed to set EFER.NX (at least) - the CPUID >> handling code specifically does not suppress this bit if the guest >> is allowed to use PAE (which we agreed a few days ago should >> be the default anyway). >> >> Jan >> > > I agree that we should allow 32-bit guests to set EFER.NX on the PAE > Xen. We'll fix it. EFER.SCE should not be set on IA-32.