Date: Thu, 13 Mar 2008 14:56:22 -0700 From: "Rao, Nikhil" <nikhil.rao@intel.com> To: "John Giacomoni" <john.giacomoni@colorado.edu> Cc: freebsd-hackers@freebsd.org Subject: RE: Shared VM address range across processes Message-ID: <12A5C15467D5B94F8E0FF265D9498ADD02B6AFB3@orsmsx419.amr.corp.intel.com> In-Reply-To: <1339BE9A-9B99-49D0-B626-FD64C442D1EE@colorado.edu> References: <12A5C15467D5B94F8E0FF265D9498ADD02B35F81@orsmsx419.amr.corp.intel.com> <006DB5A0-3669-473B-84B6-E3C8CC3C059D@colorado.edu> <12A5C15467D5B94F8E0FF265D9498ADD02B6AF6A@orsmsx419.amr.corp.intel.com> <1339BE9A-9B99-49D0-B626-FD64C442D1EE@colorado.edu>
next in thread | previous in thread | raw e-mail | index | archive | help
You still need to add the VA range to the proc->vm_space of every process right ? Nikhil -----Original Message----- From: John Giacomoni [mailto:john.giacomoni@colorado.edu]=20 Sent: Thursday, March 13, 2008 2:50 PM To: Rao, Nikhil Cc: freebsd-hackers@freebsd.org 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:john.giacomoni@colorado.edu] > Sent: Thursday, March 13, 2008 9:13 AM > To: freebsd-hackers@freebsd.org > 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 >> >> _______________________________________________ >> freebsd-hackers@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-hackers >> To unsubscribe, send any mail to > "freebsd-hackers-unsubscribe@freebsd.org >> " > > > -- > > John.Giacomoni@colorado.edu > University of Colorado at Boulder > Department of Computer Science > Engineering Center, ECCR 1B50 > 430 UCB > Boulder, CO 80303-0430 > USA > > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org=20 > " -- John.Giacomoni@colorado.edu University of Colorado at Boulder Department of Computer Science Engineering Center, ECCR 1B50 430 UCB Boulder, CO 80303-0430 USA
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?12A5C15467D5B94F8E0FF265D9498ADD02B6AFB3>