RE: [Xen-devel] Re: [Xen-changelog] Fix NX/XD enable on secondary CPUs.

["Petersson, Mats" <mats.petersson@xxxxxxx>]

Whether the processor is in 32 or 64-bit mode, if NX is used, then
EFER_NX needs to be set. If NX isn't used, then it's a "Don't care". I
think bad things happens if you set the NX bit in the page table and
don't have EFER_NX set...

--
Mats 

> -----Original Message-----
> From: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx 
> [mailto:xen-devel-bounces@xxxxxxxxxxxxxxxxxxx] On Behalf Of 
> Keir Fraser
> Sent: 13 July 2005 11:52
> To: Gerd Knorr
> Cc: xen-devel@xxxxxxxxxxxxxxxxxxx
> Subject: Re: [Xen-devel] Re: [Xen-changelog] Fix NX/XD enable 
> on secondary CPUs.
> 
> 
> Does EFER_NX need setting for 32-bit PAE?
> 
> We don't set it for *any* cpus in x86_32 builds, even cpu0...
> 
>   -- Keir
> 
> On 13 Jul 2005, at 11:17, Gerd Knorr wrote:
> 
> > I think I have this problem with PAE as well.  Machine is SMP 
> > (hyperthreaded).  PAE dom0 boots fine on CPU #0.  PAE domU 
> is bound to 
> > CPU #1 by default and boots to the login prompt as well, 
> but only with 
> > NX disabled (and network disabled, but that's another story ...).
> >
> > With NX-enabled domU boot I get this ...
> >
> >   (XEN) (file=traps.c, line=872) Non-priv domain attempted 
> > RDMSR(c0000080,00000000,20100000).
> >   (XEN) (file=traps.c, line=864) Non-priv domain attempted 
> > WRMSR(c0000080,00000800,00000000).
> >
> > ... and the kernel crashes shortly later, I guess due to NX 
> pte entry 
> > without NX being enabled on CPU #1.  It crashes right after 
> the first 
> > set_fixmap call which creates a pte entry with NX set.
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@xxxxxxxxxxxxxxxxxxx
> http://lists.xensource.com/xen-devel
> 


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