G5 Bridge-mode MMU

[Nathan Whitehorn]

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.