Hello, Thanks for the "atop" tip, now I'm able to pass the memory around, but the kernel crashes shortly after reading the value from the returned memory region:
panic: kernel diagnostic assertion "uvm_page_locked_p(pg)" failed: file "/usr/src-current/src/sys/arch/x86/x86/pmap.c", line 3215 cpu0: Begin traceback... copyright() at ffffffff8098aed4 uvm_fault(0xffffffff80cbc5a0, 0x2bb13000, 1) -> e fatal page fault in supervisor mode trap type 6 code 0 rip ffffffff8022d887 cs e030 rflags 10246 cr2 2bb13a50 cpl 0 rsp ffffa0002bb130e0 Skipping crash dump on recursive panic panic: trap Faulted in mid-traceback; aborting...rebooting... I still have to look into this (I'm going to try to mark the memory as loked using uvm_vslock, but I'm not really sure if that is going to help). 2011/9/9 Eduardo Horvath <e...@netbsd.org>: > On Wed, 7 Sep 2011, Roger Pau Monné wrote: > >> Basically we use pud_request to pass the request to the user-space >> server, and the server returns a memory address, allocated in the >> user-space memory of it's process. Then I try to read the value of the >> user space memory from the kernel, which works ok, I can fetch the >> correct value. After reading the value (that is just used for >> debugging), the physical address of the memory region is collected >> using pmap_extract and returned. > > I'm not sure you can do this. The mmap() interface in drivers is designed > to hand out unmanaged pages, not managed page frames. Userland processes > use page frames to hold pages that could be paged out at any time. You > could have nasty problems with wiring and reference counts. What you > really need to do here is shared memory not a typical device mmap(). > > WHY do you want to do this? What is PUD? Why do you have kernel devices > backed by userland daemons? I think a filesystem may be more appropriate > than a device in this case. PUD is a framework present in NetBSD that allows to implement character and block devices in userspace. I'm trying to implement a blktap [1] driver purely in userspace, and the mmap operation is needed (and it would also be beneficial for PUD to have the full set of operations implemented, for future uses). The implementation of blktap driver using fuse was discused in the port-xen mailing list, but the blktap driver needs a set of specific operations over character and block devices. My main concern is if it is possible to pass memory form a userspace program to another trough the kernel (that is mainly what my mmap implementation tries to accomplish). I trough that I could accomplish this by making the memory wired using mlock (which assures that the physical address of the memory is always the same) and then passing this block of memory around, but it looks like it's going to be be much more complicated than that, suggestions are welcome. Thanks for all the help, Roger. [1] http://lxr.xensource.com/lxr/source/tools/blktap/
