G5 Bridge-mode MMU

[Peter Grehan]

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.