Xen devel - Jun 2005 - RE: [patch] (resend) mask out nx bits when calculatingpfn/mfn

On Tue, Jun 07, 2005 at 10:16:19AM -0700, Nakajima, Jun wrote:
> Right now, it''s disabled (because Xen does not like it) in
setup64.c
> (see below). Adding NX support is on my plate, but welcome to take it.
> See http://wiki.xensource.com/xenwiki/XenTodoList.
Ah, i had missed this line:

   u64 __supported_pte_mask = ~_PAGE_NX;
> >> We also need to fix Xen because Xen should not reject the request
> >> just because it has the NX bit on.
> > 
> > An NX bit is now an official part of a page frame number???
> > 
> > i''m confused
> No, Xen should mask off the bit when calculating the page frame number,
> and looks like it''s not happening. 
I''ll poke around and try to find who''s setting the NX bit. Its
still
not clear to me though why my patch isn''t valid. Maybe the traceback
will help:

(XEN) (file=dom_mem_ops.c, line=101) Domain 0 page number out of range
(80000000016b0 >= 180000)
----------- [cut here ] --------- [please bite here ] ---------
Kernel BUG at pci_dma:98
invalid operand: 0000 [1] 
CPU 0 
Modules linked in:
Pid: 10266, comm: ifconfig Not tainted 2.6.11.11-xen0
RIP: e030:[<ffffffff80113bdc>]
<ffffffff80113bdc>{xen_contig_memory+460}
RSP: e02b:ffff880008881ca8  EFLAGS: 00010297
RAX: 00000000ffffffff RBX: ffff88000e840000 RCX: ffffffff80113bd8
RDX: 0000000000000001 RSI: ffff880008881cc8 RDI: 0000000000000001
RBP: 0000000000000000 R08: 0000000000007ff0 R09: ffff880008881cc8
R10: 0000000000000000 R11: 0000000000000293 R12: 003fffe20023a100
R13: 000000000003a100 R14: ffff88000e840000 R15: 0000000000000001
FS:  00002aaaaaac1250(0000) GS:ffffffff804f2400(0000) knlGS:0000000000000000
CS:  e033 DS: 0000 ES: 0000
Process ifconfig (pid: 10266, threadinfo ffff880008880000, task
ffff880000f3c230)
Stack: ffff880008881cc8 0000002000000000 0000000000000000 0000000400000000 
       00080000000016b0 ffff88000e840000 0000000000000004 0000000000000020 
       ffff880000b02870 0000000000009000 
Call Trace:<ffffffff80113f97>{dma_alloc_coherent+343}
<ffffffff80274d31>{e100_alloc_cbs+113}
       <ffffffff80275c00>{e100_up+48}
<ffffffff80276db8>{e100_open+56}
       <ffffffff80330f23>{dev_open+67}
<ffffffff8033257a>{dev_change_flags+90}
       <ffffffff80367ee9>{devinet_ioctl+697}
<ffffffff80369fe7>{inet_ioctl+87}
       <ffffffff8032894c>{sock_ioctl+588}
<ffffffff80168c21>{do_ioctl+33}
       <ffffffff80168f83>{vfs_ioctl+419}
<ffffffff80168fed>{sys_ioctl+77}
       <ffffffff8010d421>{system_call+125}
<ffffffff8010d3a4>{system_call+0}
       

If you look at free_dom_mem(), where the DPRINTK is called, the mfn is
being copied directly from the user. The hypervisor then checks it to
make sure that its not out of bounds with max_page, which is where we
fail. This is why i''m still skeptical that we want the hypervisor to
have to mask off bits in this exact code.

sRp

-- 
Scott Parish
Signed-off-by: srparish@us.ibm.com

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

Scott Parish wrote:
> On Tue, Jun 07, 2005 at 09:58:20AM -0700, Nakajima, Jun wrote:
> 
>> But did you really see the NX bit? I think that (NX bit) would be a
>> good catch and it explains several failures of device drivers.  We
>> should fix the creator of the pte (by __supported_pte_mask), not the
>> consumer of it.
> 
> I was seeing it in xen_contig_memory(), which was getting called by
> e100_alloc_cbs(). The crash was happening when i would run "xend
> start" 
> 
> By "fix the creator", your suggesting that there
shouldn''t be an NX
> bit set? Why?
Right now, it''s disabled (because Xen does not like it) in setup64.c
(see below). Adding NX support is on my plate, but welcome to take it.
See http://wiki.xensource.com/xenwiki/XenTodoList.


void __init check_efer(void)
{
	unsigned long efer;

        /*	rdmsrl(MSR_EFER, efer);  */

        /*
         * At this point, Xen does not like the bit 63.
         * So NX is not supported. Come back later.
         */
        efer = 0;

        if (!(efer & EFER_NX) || do_not_nx) { 
                __supported_pte_mask &= ~_PAGE_NX; 
        }       
}
> 
>> We also need to fix Xen because Xen should not reject the request
>> just because it has the NX bit on.
> 
> An NX bit is now an official part of a page frame number???
> 
> i''m confused
No, Xen should mask off the bit when calculating the page frame number,
and looks like it''s not happening. 
> 
> sRp

Jun
---
Intel Open Source Technology Center

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