From owner-freebsd-ppc@FreeBSD.ORG Wed Apr 23 16:09:53 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 302E9106567A; Wed, 23 Apr 2008 16:09:53 +0000 (UTC) (envelope-from nathanw@uchicago.edu) Received: from agogare.doit.wisc.edu (agogare.doit.wisc.edu [144.92.197.211]) by mx1.freebsd.org (Postfix) with ESMTP id E5A948FC15; Wed, 23 Apr 2008 16:09:52 +0000 (UTC) (envelope-from nathanw@uchicago.edu) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; charset=ISO-8859-1; format=flowed Received: from avs-daemon.smtpauth2.wiscmail.wisc.edu by smtpauth2.wiscmail.wisc.edu (Sun Java(tm) System Messaging Server 6.3-5.02 (built Oct 12 2007; 32bit)) id <0JZS0050MCWGP300@smtpauth2.wiscmail.wisc.edu>; Wed, 23 Apr 2008 11:09:52 -0500 (CDT) Received: from trantor.tachypleus.net ([76.201.159.245]) by smtpauth2.wiscmail.wisc.edu (Sun Java(tm) System Messaging Server 6.3-5.02 (built Oct 12 2007; 32bit)) with ESMTPSA id <0JZS003FKCW8TF20@smtpauth2.wiscmail.wisc.edu>; Wed, 23 Apr 2008 11:09:45 -0500 (CDT) Date: Wed, 23 Apr 2008 11:14:38 -0500 From: Nathan Whitehorn In-reply-to: <48050FAC.6080407@freebsd.org> To: grehan@freebsd.org Message-id: <480F606E.3000805@uchicago.edu> X-Spam-Report: AuthenticatedSender=yes, SenderIP=76.201.159.245 X-Spam-PmxInfo: Server=avs-10, Version=5.4.1.325704, Antispam-Engine: 2.6.0.325393, Antispam-Data: 2008.4.23.85130, SenderIP=76.201.159.245 References: <4804AE13.2060600@uchicago.edu> <4804C9E9.6010303@freebsd.org> <4804ECBA.5030905@uchicago.edu> <48050FAC.6080407@freebsd.org> User-Agent: Thunderbird 2.0.0.12 (X11/20080322) 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 List-Id: Porting FreeBSD to the PowerPC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Apr 2008 16:09:53 -0000 I just wanted to let everyone know that I just saw the FreeBSD copyright notice go by on my iMac G5 (it stills hangs right after the WITNESS warning). Apparently I'm on PPC kernel #160 at the moment... -Nathan Peter Grehan wrote: > 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.