use of BAT before taking over the MMU

Benjamin Herrenschmidt benh at kernel.crashing.org
Tue Oct 5 19:09:19 EST 2010


On Sat, 2010-10-02 at 14:32 -0400, Albert Cahalan wrote:
> On the prom boot path, with the firmware supposed to
> be managing the MMU, there is a case where:
> 
> 1. Linux changes some BAT registers.
> 2. Bits 0x00000070 are/become set in the MSR.
> 3. Linux takes an MMU fault.

Meeep ! Linux should never take an MMU fault at that point :-) If it
does, then there's a bug somewhere that needs squashing.

> 4. The firmware handles it.
> 
> AFAIK, you can't expect the firmware to leave the BAT alone.
> If the firmware provides mapping services by using the BAT
> as a software-filled TLB, Linux's BAT changes may be lost.
> 
> You also can't expect that your BAT changes will not conflict
> with mappings that the firmware uses for itself. The firmware
> might write to your new BAT mapping, relying on those virtual
> addresses to be something else entirely.

Right, which is why the moment Linux takes over the BATs, it shouldn't
call into FW anymore nor take faults.

Cheers,
Ben.




More information about the Linuxppc-dev mailing list