Date: Tue, 15 Apr 2008 13:27:24 -0700 From: Peter Grehan <grehan@freebsd.org> To: Nathan Whitehorn <nathanw@uchicago.edu> Cc: freebsd-ppc@freebsd.org Subject: Re: G5 Bridge-mode MMU Message-ID: <48050FAC.6080407@freebsd.org> In-Reply-To: <4804ECBA.5030905@uchicago.edu> References: <4804AE13.2060600@uchicago.edu> <4804C9E9.6010303@freebsd.org> <4804ECBA.5030905@uchicago.edu>
next in thread | previous in thread | raw e-mail | index | archive | help
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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?48050FAC.6080407>