mpc8xx DCBZ (&friends) hw bug. Tests, analysis + conclusions.

[Joakim Tjernlund]

Great job Till!

I have forwarded this to Motorola. Primarly I want to know if never silicon
behaves the same way.

> Here are the (corrected) results of some tests I ran
> on my mpc860t (XPC860TZP50B5 / 3J21M).
>
> I use mpc8bug on a FADS board to load motorola's
> 'init860.S' example. The example was slightly
> modified to include (1-4 use differend EAs, of
> course).
>
>    1) a 1:1 TLB to DRAM, R/W access (already present
>       in the vanilla code)
>
>    2) a TLB to map DRAM r/w, caching inhibited
>
>    3) a TLB to map DRAM r/o (behavior is the same
>       if for a 'real RO' mapping and for a RW
>       mapping with the 'CHANGE' bit cleared).
>
>    4) a TLB to map DRAM r/w but with the VALID
>       bit clear.

Level1 or Level2 valid bit? Does it matter which one?

>
>    5) a 'main' routine which executes the
>       instructions under test through one
>       of the aforementioned TLB mappings.

hmm, I wonder if the Guarded bit would change anything.

>
> Here's what I found (I generally load bogus
> values into MD_EPN/DAR prior to executing any
> of the cache instructions under test)
>
> A) All of dcbf, dcbi, dcbst, dcbz (dcbt and dcbtst
>      should not and do not) raise a TLBMiss exception
>      with MD_EPN set correctly but failing to set DAR
>      (i.e. DAR is left unmodified) when trying to
>      access an address not in any of the TLBs.
>
> B) All of dcbf, dcbi, dcbst, dcbz raise a TLBError
>      exception when accessing mapping 4) [as they should].
>
>      Unlike regular loads/stores (non-cache instructions),
>      NEITHER DAR not MD_EPN are set, however. DAR is left
>      unmodified MD_EPN has the CASID and reserved bits set/reset
>      but leaves the EPN bits unmodified.
>
> C) dcbi and dcbz behave like B) when accessing
>      through 3) [RO mapping]. Note that dcbf and
>      dcbst are treated like 'loads' and hence do
>      not raise a TLBError due to protection violation
>      (in accordance with the docs).
>
> D) dcbz through a cache inhibited mapping (2)) does
>      not generate an alignment exception but
>      transparently clears the memory (either is allowed
>      according to the PPC specs).
>
> Note: dcbt/dcbtst were included in all of the
> tests but they never raise an exception which is
> the correct behavior.
>
> CONCLUSION:
>
>    - the only correct workaround for TLBError
>      is the one I suggested earlier: TLBError
>      handler has to inspect the faulting opcode
>      and fixup DAR and MD_EPN based on the GPR
>      values if the faulting instruction is any
>      of dcbf, dcbi, dcbst or dcbz.
>      Performance of this solution could be
>      improved (eliminate opcode-check in the
>      vast majority of the cases) by storing
>      a 'tag' value in DAR.

Yes, but I can't even figure out how to read the instruction. Address translation
is off so how do I figure out the real address?

hmm, what does mfspr r20, M_TWB return when MD_EPN contain old EPN? The old EPN in
MD_EPN or does M_TWB know real address that generated the fault?

>
>    - the aforementioned workaround also could handle
>      TLBMiss - although performance is more of an issue
>      there.
>      Alternatives are
>         a) Jocke's workaround: copy MD_EPN -> DAR
>            (disadvantage: DAR truncated to page
>            boundary).
>         b) like a) but do this only if the faulting
>            instruction is any dcbxx (disadvantage:
>            performance loss).
>         c) merge significant bits of MD_EPN into
>            DAR. Thus, only cache instructions suffer
>            from an incorrect page offset in DAR.
>            At the same time, it's cheap.
>
> Based on the analysis, I'd suggest to implement
> the 'fixup' workaround for TLBError and alternative
> c) for TLBMiss

The TLB Miss workaround only needs to be in the slow path(DataAccess path) and
yes, it should be alternative c).


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