From owner-freebsd-hackers@FreeBSD.ORG Tue Jun 21 17:08:52 2005 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3944116A41C for ; Tue, 21 Jun 2005 17:08:52 +0000 (GMT) (envelope-from jhb@FreeBSD.org) Received: from mv.twc.weather.com (mv.twc.weather.com [65.212.71.225]) by mx1.FreeBSD.org (Postfix) with ESMTP id F1CFD43D49 for ; Tue, 21 Jun 2005 17:08:51 +0000 (GMT) (envelope-from jhb@FreeBSD.org) Received: from [10.50.41.231] (Not Verified[65.202.103.25]) by mv.twc.weather.com with NetIQ MailMarshal (v6, 0, 3, 8) id ; Tue, 21 Jun 2005 13:22:22 -0400 From: John Baldwin To: freebsd-hackers@freebsd.org, Aziz Kezzou Date: Tue, 21 Jun 2005 11:24:38 -0400 User-Agent: KMail/1.8 References: <37273927050614012154fdb80b@mail.gmail.com> <200506201037.43599.jhb@FreeBSD.org> <3727392705062012385d75d5c0@mail.gmail.com> In-Reply-To: <3727392705062012385d75d5c0@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200506211124.39587.jhb@FreeBSD.org> Cc: Andrey Simonenko Subject: Re: FreeBSD Memory Management questions ? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jun 2005 17:08:52 -0000 On Monday 20 June 2005 03:38 pm, Aziz Kezzou wrote: > On 6/20/05, John Baldwin wrote: > > On Sunday 19 June 2005 10:49 pm, Aziz Kezzou wrote: > > > > On Tue, Jun 14, 2005 at 04:21:41AM -0400, Aziz Kezzou wrote: > > > > > 1 - Right now to access the memory address space of a user process > > > > > from kernel mode, I only have to set, on x86 systems, the register > > > > > CR3 to the right value. How can I do that on other architectures ? > > > > > is there an architecture-independant way of doing that ? > > > > > > > > Addition to the previous answer. It is also possible to temporally > > > > map several pages of user memory into the kernel address space. > > > > Check pmap_qenter(9) and see physio -> vmapbuf, for example, how to > > > > use it. Another method, it is possible to COW a single user page and > > > > then use it in the kernel, but with this method an user process will > > > > not see any modification in this page made by the kernel and vice > > > > versa. Check socow_setup -> vm_page_cowsetup, for example, how to > > > > use it. > > > > > > Very interesting ! > > > > > > Right now I am using the fact that the kernel address space is maped > > > on i386 machines into the user address space. So when I am executing a > > > system call I can access kernel memory. > > > I am wondering if there is an architecture-independant way of doing > > > that ? (Notice that I need not only read kernel memory but also free > > > it. e.g, mbufs ) or at least could you tell me if that's possible on > > > other architectures ? > > > > Are you modifying kernel memory from userland or are you trying to access > > user memory from kernel code? > > I want to be able to modify BOTH user and kernel memory in kernel mode. > > Typically, a user process invoques a system call. While executing the > system call I need to have r/w access to the calling process's memory > (which is normally OK) and also r/w access to kernel's memory. Note : > the user pages that are access from kernel mode are wired to avoid a > page-fault inside the kernel, is that necessary ? No, it does not have to be wired though you might have a performance reason for doing so. You can access user memory from the kernel using the copyin() and copyout() functions which copy from from user memory to kernel memory and vice versa, respectively. > Also is there a way of sharing part of the user memory space with the > kernel. In a way that both have access to it and both see each others > work (i.e, no copy-on-write ) ? Yes. One way to do this is to create a pseudo-device that creates an entry in /dev and have it malloc() some memory and then allow the user to map that memory via mmap on the device in /dev. This might only work well on platforms that have vtophys() however. On platforms with an IOMMU like sparc64 I'm not sure if we have a good way of getting the processor PA in your mmap() routine of the memory you've allocated. There might be some other tricks you can do by speaking to the VM directly and having a system call or device ioctl() method that malloc's some memory and then uses the VM directly to map it into the address space of the current process. You'd have to look at how the vm_mmap() routine works to figure this out I think. -- John Baldwin <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve" = http://www.FreeBSD.org