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/
