[atomchild411]

cpu: four fixes to the full R10000 cache model

No machine runs the full R10000 model today (IP28 uses the shadow cache), so these are latent on main; they matter to anything that runs the full model, as the O2 does through its PROM. One commit each.

1. Index cache ops reach both ways. On the R10000, Index_WB_Inv, Index_Load/Store_Tag and Index_Load/Store_Data take the way from address bit 0. The full model is direct-mapped at the full cache size and ignored that bit, so a whole-cache flush reached only the lower half of L1I, L1D and L2; dirty lines in the upper half were written back later, over reused pages (OpenBSD/sgi on an R10000 O2: forked ksh processes died with SIGBUS). Way 1 now maps to the upper half, for tag and data ops alike.
2. 44 virtual address bits. CpuCache used CpuModel's default of 40 for every model; the shadow model already says 44 for the R10000. XContext's fields are laid out around that width, so a 64-bit kernel's TLB refill handler on a full-model R10000 would find the wrong page-table entry.
3. No debug print on every secondary Index_Store_Tag. It printed 32768 lines each time firmware initialised the cache.
4. No VCE on the R10000. Virtual coherency exceptions are an R4000/R4400 feature. On a secondary hit under a different virtual index, the R10000 writes back and drops the primary copies made under the old index and records the new one; the full model raised the R4400's VCEI/VCED instead, which an R10000 kernel never expects.

Tests

• New unit tests: the_r10000_full_model_has_44_va_bits, and the_r10000_resolves_a_colour_mismatch_where_the_r4400_raises_vce (one line under two colours: VCE on the R4400; on the R10000 the load succeeds and a store under one colour is what a load under the other sees). r10000_index_flush_reaches_both_ways for the index ops (fails without the fix).
• cargo test --lib: all pass, apart from the two tests that fail the same way on main here. Built in the three CI configurations.

🤖 Generated with Claude Code