Skip to content

MIPS r4k "TLB modified exception" generated for TLB entries that are not visible to the TLBP instruction

This bug has been copied automatically from: https://bugs.launchpad.net/qemu/+bug/1128935

I occasionally see that the TLBP instruction fails to find the
corresponding TLB entry in the TLB Modified exception handler.  This
behavior is unexpected, because the invocation of the TLB Modified
exception suggests there indeed is such an entry in the TLB and only
requires its dirty bit to be set.

The operating system which can trigger and is susceptible to this behavior
is a HelenOS branch located in lp:~jakub/helenos/mips-malta. The QEMU
version on which this is reproducible is QEMU 1.4.0 and also some others.

When I looked into the QEMU sources, I noticed the following discrepancy,
which could potentially explain the behavior:

  65  /* MIPS32/MIPS64 R4000-style MMU emulation */
  66 int r4k_map_address (CPUMIPSState *env, hwaddr *physical, int *prot,
  67                      target_ulong address, int rw, int access_type)
  68 {
  <snip>
  72     for (i = 0; i < env->tlb->tlb_in_use; i++) {

1865 void r4k_helper_tlbp(CPUMIPSState *env)
1866 {
 <snip>
1875     for (i = 0; i < env->tlb->nb_tlb; i++) {

From the above it appears as if the the code which searches the TLB for a
matching entry searched also the QEMU-specific "shadow" TLB entries, which
is, however, not in line with how the TLBP instruction searches the TLB.
So if a matching entry is found on index >= tlb_in_use, the HelenOS
exception handler using TLBP to locate the entry would hit an assertion on
seeing the Index register bit P set.

I also suspect there is a similar issue with the TLB Invalid exception,
but thanks to the specifics of the MIPS 4Kc CPU, HelenOS is not
susceptible in this case.
To upload designs, you'll need to enable LFS and have an admin enable hashed storage. More information