From owner-freebsd-hackers@FreeBSD.ORG Mon Jun 20 19:38:45 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 4CE8716A41C for ; Mon, 20 Jun 2005 19:38:45 +0000 (GMT) (envelope-from french.linuxian@gmail.com) Received: from zproxy.gmail.com (zproxy.gmail.com [64.233.162.195]) by mx1.FreeBSD.org (Postfix) with ESMTP id CD36643D1F for ; Mon, 20 Jun 2005 19:38:44 +0000 (GMT) (envelope-from french.linuxian@gmail.com) Received: by zproxy.gmail.com with SMTP id 12so672626nzp for ; Mon, 20 Jun 2005 12:38:44 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=ZAC9PkY8FlXYM7TKn42rS2WAsuSjZadIl4txeBMLQObYSMCTB5+Xyd0wqLNRfIlTeQgbW6ketG9O3OXtJbAMIhsPdubKoBv0LOYJ8VMPeviv7bOYOm9SyaWxnp9sV9BiR9aeSckVZpehT/XnPKn6Gk870PqepD9/gLWgJYiqd98= Received: by 10.36.80.15 with SMTP id d15mr3415267nzb; Mon, 20 Jun 2005 12:38:43 -0700 (PDT) Received: by 10.36.57.3 with HTTP; Mon, 20 Jun 2005 12:38:43 -0700 (PDT) Message-ID: <3727392705062012385d75d5c0@mail.gmail.com> Date: Mon, 20 Jun 2005 15:38:43 -0400 From: Aziz Kezzou To: John Baldwin In-Reply-To: <200506201037.43599.jhb@FreeBSD.org> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <37273927050614012154fdb80b@mail.gmail.com> <20050614120706.GA539@pm514-9.comsys.ntu-kpi.kiev.ua> <3727392705061919494ea7e0ad@mail.gmail.com> <200506201037.43599.jhb@FreeBSD.org> Cc: freebsd-hackers@freebsd.org, Andrey Simonenko Subject: Re: FreeBSD Memory Management questions ? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Aziz Kezzou List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jun 2005 19:38:45 -0000 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 ? >=20 > Are you modifying kernel memory from userland or are you trying to access= user > memory from kernel code? >=20 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 ? 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 ) ? Thanks, -aziz