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

["Scott Parish" <srparish@xxxxxxxxxx>]

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@xxxxxxxxxx

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