From owner-freebsd-hackers@FreeBSD.ORG Tue Jun 21 13:59:37 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 0500316A41C; Tue, 21 Jun 2005 13:59:37 +0000 (GMT) (envelope-from simon@comsys.ntu-kpi.kiev.ua) Received: from comsys.ntu-kpi.kiev.ua (comsys.ntu-kpi.kiev.ua [195.245.194.142]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4C0A043D1D; Tue, 21 Jun 2005 13:59:28 +0000 (GMT) (envelope-from simon@comsys.ntu-kpi.kiev.ua) Received: from pm514-9.comsys.ntu-kpi.kiev.ua (pm514-9.comsys.ntu-kpi.kiev.ua [10.18.54.109]) (authenticated bits=0) by comsys.ntu-kpi.kiev.ua (8.12.10/8.12.10) with ESMTP id j5LE5NFl040129 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 21 Jun 2005 17:05:23 +0300 (EEST) Received: by pm514-9.comsys.ntu-kpi.kiev.ua (Postfix, from userid 1000) id CEFC7329; Tue, 21 Jun 2005 16:57:53 +0300 (EEST) Date: Tue, 21 Jun 2005 16:57:53 +0300 From: Andrey Simonenko To: Aziz Kezzou Message-ID: <20050621135753.GA367@pm514-9.comsys.ntu-kpi.kiev.ua> References: <37273927050614012154fdb80b@mail.gmail.com> <20050614120706.GA539@pm514-9.comsys.ntu-kpi.kiev.ua> <3727392705061919494ea7e0ad@mail.gmail.com> <200506201037.43599.jhb@FreeBSD.org> <3727392705062012385d75d5c0@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3727392705062012385d75d5c0@mail.gmail.com> User-Agent: Mutt/1.4.2.1i X-Spam-Status: No, score=-4.5 required=5.0 tests=ALL_TRUSTED,BAYES_00 autolearn=ham version=3.0.1 X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on comsys.ntu-kpi.kiev.ua X-Virus-Scanned: ClamAV 0.82/940/Wed Jun 15 09:58:59 2005 on comsys.ntu-kpi.kiev.ua X-Virus-Status: Clean Cc: freebsd-hackers@freebsd.org 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 13:59:37 -0000 On Mon, Jun 20, 2005 at 03:38:43PM -0400, Aziz Kezzou wrote: > On 6/20/05, John Baldwin wrote: [skipped] > > > > 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 : Having entered to the kernel a process begins to run with higher privilege and of course it should have access to the kernel address space. Can it access own user space address space directly, I think, depends on MD code, which is responsible for memory manipulation (pmap). According to my understanding, on i386 process's PDE has entries for the kernel memory (1G), which is represented with 4M pages, process uses 4K pages for its memory (3G). When a process runs in userland it uses segments selectors and corresponding segments have limits which do not allow from userspace access kernel memory. When a process runs in the kernel in case of syscall invocation, it uses another segment selectors and another corresponding segments with another limits. All this allows not to reload %cr3. Really you don't have true r/w access to the calling process's memory, since you need to honor COW mappings (such as shadow objects or private mappings of vnode's object), COW pages (used for I/O). To honor all these you need to use copyin(9) and friends, which will call vm_fault() (BTW check that copyin checks VM_MAXUSER_ADDRESS, so user process cannot specify va outside its address space). Please (somebody) correct me, if I understood something wrong. > the user pages that are access from kernel mode are wired to avoid a > page-fault inside the kernel, is that necessary ? > It depends from which parts of the kernel you will access these pages. Also sometimes needed pages in the kernel are wired, sometimes pages are hold, currently I don't completely understand difference; even more, sometimes pages are hold, but comments in functions says that these pages are wired! > 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 ) ? Please check functions names I gave in my first letter. Also you can create anon vm_object and share it between a process and the kernel or other process (like sysv_mem). Hope this can help.