From owner-freebsd-questions@FreeBSD.ORG Mon Jan 10 17:15:33 2005 Return-Path: Delivered-To: freebsd-questions@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4859316A4CE for ; Mon, 10 Jan 2005 17:15:33 +0000 (GMT) Received: from mail.gmx.net (pop.gmx.net [213.165.64.20]) by mx1.FreeBSD.org (Postfix) with SMTP id 4055E43D2D for ; Mon, 10 Jan 2005 17:15:32 +0000 (GMT) (envelope-from m@MHoerich.de) Received: (qmail invoked by alias); 10 Jan 2005 17:15:29 -0000 Received: from pD9E58229.dip.t-dialin.net (EHLO localhost) (217.229.130.41) by mail.gmx.net (mp018) with SMTP; 10 Jan 2005 18:15:29 +0100 X-Authenticated: #5114400 Date: Mon, 10 Jan 2005 18:19:33 +0100 From: Mario Hoerich To: Romil Shah Message-ID: <20050110171933.GA1230@Pandora.MHoerich.de> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.1i Organization: University of Paderborn X-Y-GMX-Trusted: 0 cc: Freebsd Subject: Re: What is the task of pmap_enter ? X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Jan 2005 17:15:33 -0000 # Romil Shah: > I am working on 2200S RAID controller and using aac driver from RELEGN4 , > aac_disk.c in the driver uses pmap_enter for coping the virtual pages to > some physical location. Not really copying (afaict) but rather assigning a physical address to a virtual one. > In FreeBSD 4.10 pmap_kenter_temporary is used which > return the address which is passed to the controller for dumping on kernel > panic where as this is not happening with pmap_enter , can any one tell me > the difference between pmap_enter and pmap_kenter_temporary (both this > file are present in i386/pmap.c. Caveat emptor: I'm no kernel hacker and thus not overly familiar with the internal workings. So buy my explanation at your own risk.;) pmap_kenter_temporary() *temporarily* maps a physical address to a virtual one, which is then returned. No change in the page table, no state-keeping whatsoever. In contrast, pmap_enter() creates persistent mappings (or alters existing ones) and changes the page table of the process to include them. That's why it doesn't need to return an address. Quoting the daemon book [McKusick et al,1999]: | On the HP300, pmap_enter() takes the following actions: | | 1. If no page-table exists for the process, a 4-MByte range is | allocated in the kernel's address space to map the process's | address space. | | 2. If the process has no segment table of its own[...], a private | one is allocated | | 3. If a physical page has not yet been allocated to the process | page-table at the location required for the new mapping, that is | done now. Kernel page-table pages are acquired from the reserved | pool allocated at bootstrap time.[...]For either kernel or user | pagetable pages, the kernel mapping for the new page is flagged | as being a pagetable page, and the physical address of the page | is recorded in the segment table. Afterwards, once existance of the entered mapping is ensured, it may change either the protection or wiring attributes (iff the exact same mapping already exists) or replace an older mapping referencing the same virtual address (but a different physical one). In the latter case, it creates a pv_table entry (iff physical address is in range of the respective pmap module) and creates a page-table entry. pmap_entry() has probably changed a little since 4.4BSD, but I think the above steps have pretty much stayed the same (modulo some architectural necessities). HTH, Mario [McKusick et al, 1999]: McKusick, Bostic, Karels, Quarterman "The design and implementation of the 4.4BSD operating system", Addison Wesley, ISBN 0-201-54979-4 --