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

Bug #1128935 reported by Jakub Jermar
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
HelenOS branches
New
Undecided
Unassigned
QEMU
Expired
Undecided
Unassigned

Bug Description

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.

Jakub Jermar (jakub)
summary: - MIPS r4k TLB modified exception generated for TLB entries not visible to
- the TLBP instruction
+ MIPS r4k "TLB modified exception" generated for TLB entries that are not
+ visible to the TLBP instruction
Revision history for this message
Jakub Jermar (jakub) wrote :

Linux under QEMU does not hit this issue because it turns out that its "TLB modified" handler does not check the P bit of the Index register after the TLBP instruction.

Revision history for this message
Thomas Huth (th-huth) wrote :

Triaging old bug tickets... can you still reproduce this issue with the latest version of QEMU? Or could we close this ticket nowadays?

Changed in qemu:
status: New → Incomplete
Revision history for this message
Jakub Jermar (jakub) wrote :

Yes, running the following command line with QEMU 2.11.0 on the HelenOS 0.7.1 image downloaded from http://www.helenos.org/releases/HelenOS-0.7.1-mips32-malta-be.boot will result in occasional "failures" of the TLBP instruction as described in this bug and as evidenced by a warning printed by HelenOS, which goes like:

  tlb_modified: TLBP failed in exception handler (badvaddr=0x7001d7d8, ASID=29).

The command line to reproduce:

  qemu-system-mips -cpu 4Kc -drive file=hdisk.img,index=0,media=disk,format=raw -device e1000,vlan=0 -net user,hostfwd=udp::8080-:8080,hostfwd=udp::8081-:8081,hostfwd=tcp::8080-:8080,hostfwd=tcp::8081-:8081,hostfwd=tcp::2223-:2223 -usb -device intel-hda -device hda-duplex -kernel HelenOS-0.7.1-mips32-malta-be.boot -nographic

It would be good if someone familiar with the mips target had a look at this.

Revision history for this message
Jakub Jermar (jakub) wrote :

A shorter command line to reproduce this with QEMU 2.11.0 and HelenOS 0.7.1 would be:

$ qemu-system-mips -cpu 4Kc -kernel HelenOS-0.7.1-mips32-malta-be.boot -nographic

Jakub Jermar (jakub)
Changed in qemu:
status: Incomplete → New
Revision history for this message
Thomas Huth (th-huth) wrote : Moved bug report

This is an automated cleanup. This bug report has been moved to QEMU's
new bug tracker on gitlab.com and thus gets marked as 'expired' now.
Please continue with the discussion here:

 https://gitlab.com/qemu-project/qemu/-/issues/94

Changed in qemu:
status: New → Expired
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.