Re: Implement mmap for PUD

[Masao Uebayashi <uebayasi%gmail.com@localhost>]

On Sat, Sep 10, 2011 at 7:24 PM, Roger Pau Monné
<roger.pau%entel.upc.edu@localhost> wrote:
> 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

It is called pipe(2), isn't it?