8xx v2.6 TLB problems and suggested workaround

[Marcelo Tosatti]

On Sat, Apr 09, 2005 at 09:03:54PM +0200, Joakim Tjernlund wrote:
> > 
> > On Apr 8, 2005, at 7:07 AM, Marcelo Tosatti wrote:
> > 
> > > 1) _tlbie() on update_mmu_cache() surrounded by CONFIG_8xx #ifdef
> > > Did you give up about it?
> > 
> > I think a tlbia() of the vaddr should work here.  No sense blowing
> > away the whole TLB cache for this.
> 
> Umm, isn't it the other way around? tlbie flushes one TLB whereas tlbia flushes
> all TLBs.

Yep

> > > What else you think can be done?
> > 
> > It would be interesting to change __flush_dcache_icache()
> > to use the 8xx SPR cache operations instead of the dcbst instruction.
> 
> yes, but I think these operates on physical addresses which makes it a bit harder.

Other than the fact of userspace dcbst users.

> 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

Why does the current code jump to page fault handler in case of store operation? 

Out of curiosity, aren't there any other valid bit combinations for DSISR other
than 0x4800 which should allow a fastpath DataTLBError ?

I can't find DSISR settings in MPC860UM.pdf neither paper manual. AFAICS it
always refer to the PEM when talking about DSISR bit assignments. 

I can't find section "7-15" as you mentioned in the other email.

> 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.

One point is that by changing the in-kernel dcbst implementation userspace is 
still vulnerable to the problem.

Now fixing the exception handler to deal with such boggosity as Joakim proposes is 
complete - it handles userspace dcbst callers. 

> > I wouldn't be surprised if it worked differently, but I'd not be
> > able to explain it :-)
> > 
> > Thanks.
> > 
> > 	-- Dan
> >