Re: Implement mmap for PUD

[Roger Pau Monné <roger.pau%entel.upc.edu@localhost>]

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 <eeh%netbsd.org@localhost>:
> 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/