Re: 8xx v2.6 TLB problems and suggested workaround

[Dan Malek <dan@embeddededge.com>]

On Apr 9, 2005, at 3:03 PM, Joakim Tjernlund wrote:

> yes, but I think these operates on physical addresses which makes it a 
> bit harder.
> I still think this can be resolved in fault.c. Replace
> 	andis.	r11, r10, 0x0200	/* If set, indicates store op */
> 	beq	2f
> in the DTLB Error handler with
> 	andis.	r11, r10, 0x4800	/* If set, indicates invalid pte or 
> protection violation */
> 	bne	2f
> In fault.c you can check if both store and invalid is set 
> simultaneously. If it is, clear
> the store flag and continue as usual.

The purpose for the code in TLB Error is to create fast path for 
tracking
writable pages as dirty.  I think we should stop writing all of this 
assembler
code and if we find anything that isn't simply updating the "dirty" 
flags, we
should bail out to the fault.c and do whatever is necessary.  This 
includes
simulating any cache instructions that fail.

As a further performance enhancement, which used to be the standard
mode for 8xx, we should allow the option to mark all writable pages as
dirty when the PTE is created.  This eliminates the TLB Error fault in 
this
case completely.  Since most 8xx systems don't do page swapping, this
has no other effect.  If it does page swapping, it may swap more pages
than necessary, or the option can be disabled to do proper paging.

Thanks.


	-- Dan