RE: [Xen-devel] EFER in HVM guests

["Li, Xin B" <xin.b.li@xxxxxxxxx>]

Is this the framework what you want?
And we still need merge the common cases here.
-Xin

>-----Original Message-----
>From: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx 
>[mailto:xen-devel-bounces@xxxxxxxxxxxxxxxxxxx] On Behalf Of Keir Fraser
>Sent: 2006年11月30日 1:22
>To: Nakajima, Jun; Jan Beulich; xen-devel@xxxxxxxxxxxxxxxxxxx; 
>Keir Fraser
>Subject: Re: [Xen-devel] EFER in HVM guests
>
>
>*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" <jun.nakajima@xxxxxxxxx> 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. 
>
>
>_______________________________________________
>Xen-devel mailing list
>Xen-devel@xxxxxxxxxxxxxxxxxxx
>http://lists.xensource.com/xen-devel
>

Attachment: cpuid.patch
Description: cpuid.patch

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel