RE: Shared VM address range across processes

You still need to add the VA range to the proc->vm_space of every
process right ?

Nikhil

-----Original Message-----
From: John Giacomoni [mailto:[e-mail]]=20
Sent: Thursday, March 13, 2008 2:50 PM
To: Rao, Nikhil
Cc: [e-mail]
Subject: Re: Shared VM address range across processes

Nikhil,

I am using kernel addresses to ensure that once the memory region is =20
allocated
it is available to everyone, even for late joiners who might have an =20
address
range conflict.

If you can predetermine or or otherwise simultaneously ensure the =20
address range
is available for everyone life maybe easier :)  I haven't looked into =20
it but
mapping userspace pages should be easier.

John G

On Mar 13, 2008, at 3:27 PM, Rao, Nikhil wrote:

>
> Hi John,
>
> Is the approach that you are working on based on necessarily using the
> kernel address space, so is this approach not feasible with user space
> virtual addresses ?
>
> Nikhil
>
> -----Original Message-----
> From: John Giacomoni [mailto:[e-mail]]
> Sent: Thursday, March 13, 2008 9:13 AM
> To: [e-mail]
> Cc: Rao, Nikhil
> Subject: Re: Shared VM address range across processes
>
> Nihkil,
>
> I'm working on something similar for a research project and the answer
> is that it is possible but ugly.
>
> First, are you sure you need to do this?  Ensuring safety by checking
> pointers before dereferencing can be painful :)
>
> FreeBSD seems to have checks scattered throughout the kernel trying to
> ensure that the kernel address range remains unavailable to the
> userspace
> address range.  These checks can obviously be bypassed but they are
> fairly
> invasive.  Once all those checks are bipassed, you need to ensure that
> the
> PTEs and PDEs are have the userspace bit set for the appropriate page
> ranges which then requires flushing the specific pages out of the TLB
> using the invlpg function, note that flushing the TLB is =20
> insufficient as
> kernel pages are marked global and thus won't flush with any other
> method.
>
> files that I touched
>
> /usr/src/sys/amd64/amd64/pmap.c  - pmap_enter
>
> /usr/src/sys/amd64/amd64/trap.c - trap_pfault
>
> and the allocation site needs to ensure that the user-mode bit is =20
> set on
> the correct PTEs and PDEs.
>
> I directly allocate memory using vm objects to help me bypass the
> various
> address range checks that can be found in the higher levels of the
> kernel.
>
> I'm planning on generalizing and cleaning my approach up in the next =20
> few
> months but I'll be glad to answer any specific questions you might =20
> have.
>
>
> For the FreeBSD kernel developers,
>
> Is there a reason to enforce the high/low mem address range as =20
> strongly
> as is done in FreeBSD?  It seems that if the higher-levels of the =20
> kernel
> allow a mapping, the lower-levels should respect that.
>
> John G
>
>
>
> On Mar 12, 2008, at 12:46 PM, Rao, Nikhil wrote:
>
>> Hi,
>>
>>
>>
>> I want to map device memory into the same virtual address range in
>> multiple processes, this means I would have to add a vm_map_entry per
>> address range in every process, since the list of processes can be
>> potentially huge .. Is it allowed to point to the same list of
>> vm_map_entrys from multiple vm_spaces ? BSD3 had a field in the
>> vm_map_entry that could be a share map - would it be an idea that I
>> could reuse ?
>>
>>
>>
>> Nikhil
>>
>> _______________________________________________
>> [e-mail] mailing list
>> http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
>> To unsubscribe, send any mail to
> "[e-mail]
>> "
>
>
> --
>
> [e-mail]
> University of Colorado at Boulder
> Department of Computer Science
> Engineering Center, ECCR 1B50
> 430 UCB
> Boulder, CO 80303-0430
> USA
>
> _______________________________________________
> [e-mail] mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
> To unsubscribe, send any mail to
"[e-mail]=20
> "


--

[e-mail]
University of Colorado at Boulder
Department of Computer Science
Engineering Center, ECCR 1B50
430 UCB
Boulder, CO 80303-0430
USA

_______________________________________________
[e-mail] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[e-mail]"