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

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

[Petersson, Mats]

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@lists.xensource.com 
> [mailto:xen-devel-bounces@lists.xensource.com] On Behalf Of 
> Keir Fraser
> Sent: 13 July 2005 11:52
> To: Gerd Knorr
> Cc: xen-devel@lists.xensource.com
> 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@lists.xensource.com
> http://lists.xensource.com/xen-devel
> 

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

[Keir Fraser]

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.

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

[Gerd Knorr]

On Wed, Jul 13, 2005 at 11:52:27AM +0100, Keir Fraser wrote:
> 
> Does EFER_NX need setting for 32-bit PAE?
> 
> We don't set it for *any* cpus in x86_32 builds, even cpu0...

The Dom0 linux kernel probably does for CPU #0 ...

> >  (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).

... what the DomU kernel isn't allowed to do on CPU #1.

  Gerd

-- 
panic("it works"); /* avoid being flooded with debug messages */

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

[Keir Fraser]

On 13 Jul 2005, at 11:45, Petersson, Mats wrote:

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

Okay, this should now be fixed in the public repository.

Hopefully domU PAE will boot much further now :-)

  -- Keir

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

[Gerd Knorr]

> Hopefully domU PAE will boot much further now :-)

Yes, works.
Thanks,

  Gerd

-- 
panic("it works"); /* avoid being flooded with debug messages */