From owner-freebsd-ppc@FreeBSD.ORG Tue Apr 15 20:28:27 2008 Return-Path: Delivered-To: freebsd-ppc@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3DEFD1065671 for ; Tue, 15 Apr 2008 20:28:27 +0000 (UTC) (envelope-from grehan@freebsd.org) Received: from alto.onthenet.com.au (alto.OntheNet.com.au [203.13.68.12]) by mx1.freebsd.org (Postfix) with ESMTP id F01138FC15 for ; Tue, 15 Apr 2008 20:28:26 +0000 (UTC) (envelope-from grehan@freebsd.org) Received: from dommail.onthenet.com.au (dommail.OntheNet.com.au [203.13.70.57]) by alto.onthenet.com.au (Postfix) with ESMTP id B5393122D7; Wed, 16 Apr 2008 06:28:22 +1000 (EST) Received: from excfreebsd.hq.netapp.com (nat-198-95-226-228.netapp.com [198.95.226.228]) by dommail.onthenet.com.au (MOS 3.7.5a-GA) with ESMTP id DVX86528 (AUTH peterg@ptree32.com.au); Wed, 16 Apr 2008 06:28:24 +1000 (EST) Message-ID: <48050FAC.6080407@freebsd.org> Date: Tue, 15 Apr 2008 13:27:24 -0700 From: Peter Grehan User-Agent: Thunderbird 2.0.0.0 (X11/20070525) MIME-Version: 1.0 To: Nathan Whitehorn References: <4804AE13.2060600@uchicago.edu> <4804C9E9.6010303@freebsd.org> <4804ECBA.5030905@uchicago.edu> In-Reply-To: <4804ECBA.5030905@uchicago.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-ppc@freebsd.org Subject: Re: G5 Bridge-mode MMU X-BeenThere: freebsd-ppc@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: grehan@freebsd.org List-Id: Porting FreeBSD to the PowerPC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Apr 2008 20:28:27 -0000 Hi Nathan, >> You really can't use the existing MMU code. The G5 was the driving >> factor to create the pmap indirection. > Yeah, the bridge mode MMU is just different enough to be annoying. I'm > using the existing code as a base, because (a) it's nice to have a > template, and (b) most of the PTE handling stuff can be reused with > s/struct pte/struct lpte and s/PTE/LPTE, and some changes to the hash > function and PTE_EXEC bits. Also, you may want to use 64-bit move instructions to atomically update PTEs in the hash table. > So you suggest saving OF's SDR1 and restoring it when we need to call > in? I guess this would solve part of the problem (debugging output while > initializing the MMU), but I'm sure sure I understand the real benefit > to this. I don't think the existing trick of putting OFW in it's own pmap will work. A full context switch, including SDR1, would give more confidence that OFW callbacks will work since it will be running in the address space it created. > So it should be generally true that all the local variables and > statically allocated things in pmap_bootstrap() should have virtual > addresses equal to their physical address? Yes, since at that point the kernel is running on a stack allocated in BSS. See tmpstk in locore.S. > Also, going to real mode seems like kind of a hack, but I think it may > be the best choice. I agree. Linux does it as well. >> - another 1:1 relic is the use of UMA_MD_SMALL_ALLOC. I talked with >> Alan Cox a long time back about being able to dynamically determine >> whether this could be used, though that is a fair amount of work. I >> would like to see a single kernel for G3/4/5, but that may be asking >> too much up front, especially given my lack of progress in achieving >> this goal :) > Well, once we have the page table set up, we can add a 1:1 mapping in > certain places -- e.g. low memory -- by adding in a whole bunch of 4 KB > pages. You have to be careful. A big advantage of the BAT mechanism is that a page's mod/ref bits aren't touched. If you have multiple mappings, you have to take care that you don't accidentally cause a page to be R/M'd when it shouldn't. Page-zeroing is an example: if you had 1:1 mappings, the page's R/M bits would have to be cleared after the zeroing. Or, make the pmap code aware of this. later, Peter.