summary refs log tree commit diff stats
path: root/results/scraper/launchpad-without-comments/1128935
diff options
context:
space:
mode:
authorChristian Krinitsin <mail@krinitsin.com>2025-06-30 12:24:58 +0000
committerChristian Krinitsin <mail@krinitsin.com>2025-06-30 12:27:06 +0000
commit33606b41d35115f887ea688b1a16f2ff85bf2fe4 (patch)
tree406b2c7b19a087ba437c68f3dbf0b589fa1d6150 /results/scraper/launchpad-without-comments/1128935
parentadedf8771bc4de3113041ca21bd4d0d1c0014b6a (diff)
downloademulator-bug-study-33606b41d35115f887ea688b1a16f2ff85bf2fe4.tar.gz
emulator-bug-study-33606b41d35115f887ea688b1a16f2ff85bf2fe4.zip
add launchpad bug reports without comments
Diffstat (limited to 'results/scraper/launchpad-without-comments/1128935')
-rw-r--r--results/scraper/launchpad-without-comments/112893523
1 files changed, 23 insertions, 0 deletions
diff --git a/results/scraper/launchpad-without-comments/1128935 b/results/scraper/launchpad-without-comments/1128935
new file mode 100644
index 00000000..71880927
--- /dev/null
+++ b/results/scraper/launchpad-without-comments/1128935
@@ -0,0 +1,23 @@
+MIPS r4k "TLB modified exception" generated for TLB entries that are not visible to the TLBP instruction
+
+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.
\ No newline at end of file