Re: Implement mmap for PUD

[Jean-Yves Migeon <jeanyves.migeon%free.fr@localhost>]

On 07.09.2011 10:33, Roger Pau Monné wrote:
> Since there is no mmap implementation for PUD devices I began working
> on one. I would like to make an implementation that avoids copying
> buffers around user-space and kernel memory, since mmap is usually
> used for fast applications. I began working on pud_dev.c file, that
> contains the kernel implementation of the mmap call, which is then
> passed to user space. My mmap function looks like:

> [snip]

> This *works* ok, the kernel doesn't panic, but if I perform a mmap on
> the device, the pud_cdev_mmap function is called forever with the same
> arguments, and the function never returns (I have to kill the
> program). Under a GENERIC kernel, I don't see any error messages, but
> using a XEN kernel, I see the following messages from the hypervisor:
> 
> (XEN) d0:v0: reserved bit in page table (ec=000D)
> (XEN) Pagetable walk from 00007f7ff7ff6000:
> (XEN)  L4[0x0fe] = 0000000838c8b027 000000000000f374
> (XEN)  L3[0x1ff] = 0000000c0a3be027 0000000000015c41
> (XEN)  L2[0x1bf] = 000000083a701027 000000000000d8fe
> (XEN)  L1[0x1f6] = 80000198ab000125 ffffffffffffffff

[snip]

> That appears every time a mmap call returns. My guess is that I have
> to mark the memory I'm returning from mmap as shared somehow, but I
> don't know how (or if it is even possible to pass memory from
> user-space programs through the kernel). Any hint on how to solve this
> problem would be really appreaciated.

Without looking at your code (or pud), somehow it manages to establish a
mapping with reserved bits set in the page entries, which is something
that will generate a fault.

(XEN) d0:v0: reserved bit in page table (ec=000D)

=> domain 0, VCPU 0, page fault by reserved bit set in page table, error
code 000D =>  8+4+1
8 - reserved bit overwrite
4 - happened while CPU was in user mode (PGEX_U)
1 - protection violation (reserved bits are... reserved) (PGEX_P)

Apparently, native kernel does not trap for this kind of error code [1]
[2]; NetBSD only defines PGEX_{P,W,U,X}. Making the fault explicit in
traps.c will probably reveal the same kind of fault as the one Xen reports.

Now, as to why and how you can fix it: dunno.

[1] http://nxr.netbsd.org/xref/src/sys/arch/x86/include/pte.h#41

[2] http://nxr.netbsd.org/xref/src/sys/arch/amd64/amd64/trap.c#525

-- 
Jean-Yves Migeon
jeanyves.migeon%free.fr@localhost