dcbz works on 862 everywhere!

[Joakim Tjernlund]

> > The current implementation relies on TLB Miss always setting EPN
> > (and other hardware assist registers) correctly, and TLB Error
> > relies on DAR being set correctly.  Everything works fine until
> > you get a TLB Error on a dcbz/dcbt that doesn't properly update DAR.
> > In this case EPN isn't set correctly either.
>
> I just want to point out(again) that TLB Miss caused by most of the
> dcxx(dcbf, dcbi, dcbst, dcbz) instructions that end up in the slow path(DataAccess)
> don't work with the current impl. since DAR isn't set. The code fragment below
> will fix that(from my earlier patch). This won't affect the fast path at all
> since it all of it can be in the slow path.
>
> +	/* Copy 20 msb from EPN to DAR since the dcxx instructions fails
> +	 * update the DAR when they cause a DTLB Miss.
> +	 */
> +	mfspr	r21, MD_EPN
> +	rlwinm	r21, r21, 0, 0, 19
> +	mfspr	r20, DAR
> +	rlwinm	r20, r20, 0, 20, 31
> +	or	r20, r20, r21
> +	mtspr	DAR, r20
>
> It is hard to end up in slow path for kernel space addresses, but
> it's not impossible I guess. Comments?

hmm, no response from the maintainer(s). You don't agree?

Did another test. I tagged DAR with a bad address(0xdead0000) in
the TLB Miss handler(after the mtspr MD_RPN, r20) shortly before
rfi.

Now the kernel won't boot. It turns out it's consistent_alloc that is
doing a invalidate_dcache_range(). According to a comment, memory is allocated
from the vmalloc memory space. Doing a invalidate_dcache_range() on this memory
causes a DTLB error with the change bit cleared and since DAR isn't set by
dcbi, linux hangs.

Clearly, the DTLB exeception procedure still is buggy.

   Jocke


** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/