From dee4dcba78baf712cab403d47d9db319ab7f95d6 Mon Sep 17 00:00:00 2001
From: Christian Krinitsin <mail@krinitsin.com>
Date: Thu, 3 Jul 2025 19:39:53 +0200
Subject: restructure results

---
 results/classifier/semantic-bugs/semantic/1156313 | 128 -------------------
 results/classifier/semantic-bugs/semantic/1370    |  26 ----
 results/classifier/semantic-bugs/semantic/1371    |  32 -----
 results/classifier/semantic-bugs/semantic/1372    |  33 -----
 results/classifier/semantic-bugs/semantic/1373    |  33 -----
 results/classifier/semantic-bugs/semantic/1374    |  35 -----
 results/classifier/semantic-bugs/semantic/1375    |  32 -----
 results/classifier/semantic-bugs/semantic/1428352 |  63 ---------
 results/classifier/semantic-bugs/semantic/1809546 |  90 -------------
 results/classifier/semantic-bugs/semantic/1923197 | 149 ----------------------
 10 files changed, 621 deletions(-)
 delete mode 100644 results/classifier/semantic-bugs/semantic/1156313
 delete mode 100644 results/classifier/semantic-bugs/semantic/1370
 delete mode 100644 results/classifier/semantic-bugs/semantic/1371
 delete mode 100644 results/classifier/semantic-bugs/semantic/1372
 delete mode 100644 results/classifier/semantic-bugs/semantic/1373
 delete mode 100644 results/classifier/semantic-bugs/semantic/1374
 delete mode 100644 results/classifier/semantic-bugs/semantic/1375
 delete mode 100644 results/classifier/semantic-bugs/semantic/1428352
 delete mode 100644 results/classifier/semantic-bugs/semantic/1809546
 delete mode 100644 results/classifier/semantic-bugs/semantic/1923197

(limited to 'results/classifier/semantic-bugs/semantic')

diff --git a/results/classifier/semantic-bugs/semantic/1156313 b/results/classifier/semantic-bugs/semantic/1156313
deleted file mode 100644
index 54d2d0f9..00000000
--- a/results/classifier/semantic-bugs/semantic/1156313
+++ /dev/null
@@ -1,128 +0,0 @@
-semantic: 0.869
-mistranslation: 0.841
-assembly: 0.789
-device: 0.777
-instruction: 0.707
-other: 0.705
-vnc: 0.702
-graphic: 0.657
-socket: 0.605
-boot: 0.576
-network: 0.533
-KVM: 0.518
-
-X86-64 flags handling broken
-
-The current qemu sources cause improper handling of flags on x86-64.
-This bug seems to have shown up a few weeks ago.
-
-A plain install of Debian GNU/Linux makes user processes catch
-spurious signals.  The kernel seems to run stably, though.
-
-The ADX feature works very poorly.  It might be related; at least it
-allows for reproducibly provoking invalid behaviour.
-
-Here is a test case:
-
-================================================================
-qemumain.c
-#include <stdio.h>
-long adx();
-int
-main ()
-{
-  printf ("%lx\n", adx (0xffbeef, 17));
-  return 0;
-}
-================================================================
-qemuadx.s:
-        .globl  adx
-adx:    xor     %rax, %rax
-1:      dec     %rdi
-        jnz     1b
-        .byte 0xf3, 0x48, 0x0f, 0x38, 0xf6, 0xc0        # adox  %rax, %rax
-        .byte 0x66, 0x48, 0x0f, 0x38, 0xf6, 0xc0        # adcx  %rax, %rax
-        ret
-================================================================
-
-Compile and execute:
-$ gcc -m64 qemumain.c qemuadx.s
-$ a.out
-ffffff8000378cd8
-
-Expected output is simply "0".  The garbage value varies between qemu
-compiles and guest systems.
-
-Note that one needs a recent GNU assembler in order to handle adox and
-adcx.  For convenience I have supplied them as byte sequences.
-
-Exaplanation and feeble analysis:
-
-The 0xffbeef argument is a loop count.  It is necessary to loop for a
-while in order to trigger this bug.  If the loop count is decreased,
-the bug will seen intermittently; the lower the count, the less
-frequent the invalid behaviour.
-
-It seems like a reasonable assumption that this bug is related to
-flags handling at context switch.  Presumably, qemu keeps flags state
-in some internal format, then recomputes then when needing to form the
-eflags register, as needed for example for context switching.
-
-I haven't tried to reproduce this bug using qemu-x86_64 and SYSROOT,
-but I strongly suspect that to be impossible.  I use
-qemu-system-x86_64 and the guest Debian GNU/Linux x86_64 (version
-6.0.6) .
-
-The bug happens also with the guest FreeBSD x86_64 version 9.1.  (The
-iteration count for triggering the problem 50% of the runs is not the
-same when using the kernel Linux and FreeBSD's kernel, presumably due
-to different ticks.)
-
-The bug happens much more frequently for a loaded system; in fact, the
-loop count can be radically decreased if two instances of the trigger
-program are run in parallel.
-
-Richard Henderson <email address hidden> writes:
-
-  Patch at http://patchwork.ozlabs.org/patch/229139/
-  
-Thanks.  I can confirm that this fixes the bug triggered by my test case
-(and yours).  However, the instability of Debian GNU/Linux x86_64 has
-not improved.
-
-The exact same Debian version (debian "testing") updated at the same
-time runs well on hardware.
-
-My qemu Debian system now got messed up, since I attempted an upgrade in
-the buggy qemu, which segfaulted several times during the upgrade.  I
-need to reinstall, and then rely on -snapshot.
-
-There is a problem with denorms which is reproducible, but whether that
-is a qemu bug, and whether it can actually cause the observed
-instability, is questionable.  Here is a testcase for that problem:
-
-
-
-
-It should terminate.  The observed buggy behaviour is that it hangs.
-
-The instability problem can be observed at gmplib.org/devel/tm-date.html.
-hwl-deb.gmplib.org is Debian under qemu with -cpu Haswell,+adx.
-
-Not that the exact same qemu runs FreeBSD flawlessly (hwl.gmplib.org).
-It is neither instable nor does it run the denorms testcase poorly.
-
-I fully realise this is a hopeless bug report, but I am sure you can
-reproduce it, since it is far from GMP specific.  After all apt-get
-update; apt-get upgrade triggered it.  Debugging it will be a nightmare.
-
-Qemu version: main git repo from less than a week ago + Richard ADX
-patch.
-
--- 
-Torbjörn
-
-
-It looks from this bug that we fixed the initial ADOX bug in commit c53de1a2896cc (2013), and I've just tried the 'qemu-denorm-problem.s' test case from comment #1 and it works OK, so I think we've fixed that denormals bug too. Given that, and that this bug report is 4 years old, I'm going to close it. If you're still having problems with recent versions of QEMU, please open a new bug.
-
-
diff --git a/results/classifier/semantic-bugs/semantic/1370 b/results/classifier/semantic-bugs/semantic/1370
deleted file mode 100644
index c7f125ab..00000000
--- a/results/classifier/semantic-bugs/semantic/1370
+++ /dev/null
@@ -1,26 +0,0 @@
-semantic: 0.986
-instruction: 0.949
-graphic: 0.878
-assembly: 0.842
-device: 0.806
-socket: 0.681
-vnc: 0.658
-network: 0.606
-boot: 0.546
-mistranslation: 0.502
-other: 0.474
-KVM: 0.210
-
-x86 BLSI and BLSR semantic bug
-Description of problem:
-The result of instruction BLSI and BLSR is different from the CPU. The value of CF is different.
-Steps to reproduce:
-1. Compile this code
-```
-void main() {
-    asm("blsi rax, rbx");
-}
-```
-2. Execute and compare the result with the CPU. The value of `CF` is exactly the opposite. This problem happens with BLSR, too.
-Additional information:
-This bug is discovered by research conducted by KAIST SoftSec.
diff --git a/results/classifier/semantic-bugs/semantic/1371 b/results/classifier/semantic-bugs/semantic/1371
deleted file mode 100644
index 16aca0c8..00000000
--- a/results/classifier/semantic-bugs/semantic/1371
+++ /dev/null
@@ -1,32 +0,0 @@
-semantic: 0.995
-instruction: 0.970
-assembly: 0.852
-graphic: 0.824
-device: 0.665
-mistranslation: 0.491
-boot: 0.468
-vnc: 0.465
-socket: 0.452
-network: 0.307
-other: 0.217
-KVM: 0.064
-
-x86 BLSMSK semantic bug
-Description of problem:
-The result of instruction BLSMSK is different with from the CPU. The value of CF is different.
-Steps to reproduce:
-1. Compile this code
-```
-void main() {
-    asm("mov rax, 0x65b2e276ad27c67");
-    asm("mov rbx, 0x62f34955226b2b5d");
-    asm("blsmsk eax, ebx");
-}
-```
-2. Execute and compare the result with the CPU.
-    - CPU
-        - CF = 0
-    - QEMU
-        - CF = 1
-Additional information:
-This bug is discovered by research conducted by KAIST SoftSec.
diff --git a/results/classifier/semantic-bugs/semantic/1372 b/results/classifier/semantic-bugs/semantic/1372
deleted file mode 100644
index a5a86bb8..00000000
--- a/results/classifier/semantic-bugs/semantic/1372
+++ /dev/null
@@ -1,33 +0,0 @@
-semantic: 0.995
-instruction: 0.963
-graphic: 0.860
-device: 0.736
-assembly: 0.728
-mistranslation: 0.574
-vnc: 0.420
-boot: 0.411
-socket: 0.263
-network: 0.171
-other: 0.159
-KVM: 0.083
-
-x86 BEXTR semantic bug
-Description of problem:
-The result of instruction BEXTR is different with from the CPU. The value of destination register is different. I think QEMU does not consider the operand size limit.
-Steps to reproduce:
-1. Compile this code
-```
-void main() {
-    asm("mov rax, 0x17b3693f77fb6e9");
-    asm("mov rbx, 0x8f635a775ad3b9b4");
-    asm("mov rcx, 0xb717b75da9983018");
-    asm("bextr eax, ebx, ecx");
-}
-```
-2. Execute and compare the result with the CPU.
-    - CPU
-        - RAX = 0x5a
-    - QEMU
-        - RAX = 0x635a775a
-Additional information:
-This bug is discovered by research conducted by KAIST SoftSec.
diff --git a/results/classifier/semantic-bugs/semantic/1373 b/results/classifier/semantic-bugs/semantic/1373
deleted file mode 100644
index d4cf2ba6..00000000
--- a/results/classifier/semantic-bugs/semantic/1373
+++ /dev/null
@@ -1,33 +0,0 @@
-semantic: 0.996
-assembly: 0.951
-instruction: 0.948
-graphic: 0.898
-device: 0.784
-vnc: 0.746
-mistranslation: 0.642
-boot: 0.505
-socket: 0.502
-network: 0.373
-other: 0.248
-KVM: 0.113
-
-x86 ADOX and ADCX semantic bug
-Description of problem:
-The result of instruction ADOX and ADCX are different from the CPU. The value of one of EFLAGS is different.
-Steps to reproduce:
-1. Compile this code
-```
-void main() {
-    asm("push 512; popfq;");
-    asm("mov rax, 0xffffffff84fdbf24");
-    asm("mov rbx, 0xb197d26043bec15d");
-    asm("adox eax, ebx");
-}
-```
-2. Execute and compare the result with the CPU. This problem happens with ADCX, too (with CF).
-    - CPU
-        - OF = 0
-    - QEMU
-        - OF = 1
-Additional information:
-This bug is discovered by research conducted by KAIST SoftSec.
diff --git a/results/classifier/semantic-bugs/semantic/1374 b/results/classifier/semantic-bugs/semantic/1374
deleted file mode 100644
index 0db6a019..00000000
--- a/results/classifier/semantic-bugs/semantic/1374
+++ /dev/null
@@ -1,35 +0,0 @@
-semantic: 0.993
-instruction: 0.952
-graphic: 0.807
-device: 0.700
-assembly: 0.661
-boot: 0.382
-vnc: 0.341
-socket: 0.314
-network: 0.272
-mistranslation: 0.272
-other: 0.093
-KVM: 0.044
-
-x86 BZHI semantic bug
-Description of problem:
-The result of instruction BZHI is different from the CPU. The value of destination register and SF of EFLAGS are different.
-Steps to reproduce:
-1. Compile this code
-```
-void main() {
-    asm("mov rax, 0xb1aa9da2fe33fe3");
-    asm("mov rbx, 0x80000000ffffffff");
-    asm("mov rcx, 0xf3fce8829b99a5c6");
-    asm("bzhi rax, rbx, rcx");
-}
-```
-2. Execute and compare the result with the CPU.
-    - CPU
-        - RAX = 0x0x80000000ffffffff
-        - SF = 1
-    - QEMU
-        - RAX = 0xffffffff
-        - SF = 0
-Additional information:
-This bug is discovered by research conducted by KAIST SoftSec.
diff --git a/results/classifier/semantic-bugs/semantic/1375 b/results/classifier/semantic-bugs/semantic/1375
deleted file mode 100644
index 3d774638..00000000
--- a/results/classifier/semantic-bugs/semantic/1375
+++ /dev/null
@@ -1,32 +0,0 @@
-semantic: 0.988
-instruction: 0.945
-graphic: 0.792
-device: 0.739
-other: 0.687
-assembly: 0.675
-vnc: 0.520
-network: 0.458
-boot: 0.413
-socket: 0.407
-mistranslation: 0.269
-KVM: 0.247
-
-x86 SSE/SSE2/SSE3 instruction semantic bugs with NaN
-Description of problem:
-The result of SSE/SSE2/SSE3 instructions with NaN is different from the CPU. From Intel manual Volume 1 Appendix D.4.2.2, they defined the behavior of such instructions with NaN. But I think QEMU did not implement this semantic exactly because the byte result is different.
-Steps to reproduce:
-1. Compile this code
-```
-void main() {
-    asm("mov rax, 0x000000007fffffff; push rax; mov rax, 0x00000000ffffffff; push rax; movdqu XMM1, [rsp];");
-    asm("mov rax, 0x2e711de7aa46af1a; push rax; mov rax, 0x7fffffff7fffffff; push rax; movdqu XMM2, [rsp];");
-    asm("addsubps xmm1, xmm2");
-}
-```
-2. Execute and compare the result with the CPU. This problem happens with other SSE/SSE2/SSE3 instructions specified in the manual, Volume 1 Appendix D.4.2.2.
-    - CPU
-        - xmm1[3] = 0xffffffff
-    - QEMU
-        - xmm1[3] = 0x7fffffff
-Additional information:
-This bug is discovered by research conducted by KAIST SoftSec.
diff --git a/results/classifier/semantic-bugs/semantic/1428352 b/results/classifier/semantic-bugs/semantic/1428352
deleted file mode 100644
index b63b8ced..00000000
--- a/results/classifier/semantic-bugs/semantic/1428352
+++ /dev/null
@@ -1,63 +0,0 @@
-semantic: 0.788
-other: 0.739
-graphic: 0.673
-mistranslation: 0.665
-instruction: 0.659
-assembly: 0.653
-device: 0.631
-vnc: 0.613
-KVM: 0.595
-network: 0.538
-boot: 0.531
-socket: 0.491
-
-SYSRET instruction incorrectly implemented
-
-The Intel architecture manual states that when returning to user mode, the SYSRET instruction will re-load the stack selector (%ss) from the IA32_STAR model specific register using the following logic:
-
-SS.Selector <-- (IA32_STAR[63:48]+8) OR 3; (* RPL forced to 3 *)
-
-Another description of the instruction behavior which shows the same logic in a slightly different form can also be found here:
-
-http://tptp.cc/mirrors/siyobik.info/instruction/SYSRET.html
-
-[...]
-        SS(SEL) = IA32_STAR[63:48] + 8;
-        SS(PL) = 0x3;
-[...]
-
-In other words, the value of the %ss register is supposed to be loaded from  bits 63:48 of the IA32_STAR model-specific register, incremented by 8, and then ORed with 3. ORing in the 3 sets the privilege level to 3 (user). This is done since SYSRET returns to user mode after a system call.
-
-However, helper_sysret() in target-i386/seg_helper.c does not do the "OR 3" step. The code looks like this:
-
-        cpu_x86_load_seg_cache(env, R_SS, selector + 8,
-                               0, 0xffffffff,
-                               DESC_G_MASK | DESC_B_MASK | DESC_P_MASK |
-                               DESC_S_MASK | (3 << DESC_DPL_SHIFT) |
-                               DESC_W_MASK | DESC_A_MASK);
-
-It should look like this:
-
-        cpu_x86_load_seg_cache(env, R_SS, (selector + 8) | 3,
-                               0, 0xffffffff,
-                               DESC_G_MASK | DESC_B_MASK | DESC_P_MASK |
-                               DESC_S_MASK | (3 << DESC_DPL_SHIFT) |
-                               DESC_W_MASK | DESC_A_MASK);
-
-The code does correctly set the privilege level bits for the code selector register (%cs) but not for the stack selector (%ss).
-
-The effect of this is that when SYSRET returns control to the user-mode caller, %ss will be have the privilege level bits cleared. In my case, it went from 0x2b to 0x28. This caused a crash later: when the user-mode code was preempted by an interrupt, and the interrupt handler would do an IRET, a general protection fault would occur because the %ss value being loaded from the exception frame was not valid for user mode. (At least, I think that's what happened.)
-
-This behavior seems inconsistent with real hardware, and also appears to be wrong with respect to the Intel documentation, so I'm pretty confident in calling this a bug. :)
-
-Note that this issue seems to have been around for a long time. I discovered it while using QEMU 2.2.0, but I happened to have the sources for QEMU 0.10.5, and the problem is there too (in os_helper.c). I am using FreeBSD/amd64 9.1-RELEASE as my host system, without KVM.
-
-The fix is fairly simple. I'm attaching a patch which worked for me. Using this fix, the code that I'm testing now behaves the same on the QEMU virtual machine as on real hardware.
-
-- Bill (<email address hidden>)
-
-
-
-If I've got that right, this has been fixed here:
-https://git.qemu.org/?p=qemu.git;a=commitdiff;h=ac57622985220de0
-
diff --git a/results/classifier/semantic-bugs/semantic/1809546 b/results/classifier/semantic-bugs/semantic/1809546
deleted file mode 100644
index dfeb2f57..00000000
--- a/results/classifier/semantic-bugs/semantic/1809546
+++ /dev/null
@@ -1,90 +0,0 @@
-semantic: 0.913
-instruction: 0.876
-device: 0.860
-other: 0.855
-boot: 0.852
-assembly: 0.850
-graphic: 0.848
-network: 0.811
-mistranslation: 0.754
-vnc: 0.735
-socket: 0.612
-KVM: 0.608
-
-Writing a byte to a pl011 SFR overwrites the whole SFR
-
-The bug is present in QEMU 2.8.1 and, if my analysis is correct, also on master.
-
-I first noticed that a PL011 UART driver, which is fine on real hardware, fails to enable the RX interrupt in the IMSC register when running in QEMU. However, the problem only comes up if the code is compiled without optimizations. I think I've narrowed it down to a minimal example that will exhibit the problem if run as a bare-metal application.
-
-Given:
-
-pl011_addr: .word 0x10009000
-
-The following snippet will be problematic:
-
-     ldr r3, pl011_addr
-     ldrb r2, [r3, #0x38]        // IMSC
-     mov r2, #0
-     orr r2, r2, #0x10           // R2 == 0x10
-     strb r2, [r3, #0x38]        // Whole word reads correctly after this
-     ldrb r2, [r3, #0x39]
-     mov r2, #0
-     strb r2, [r3, #0x39]        // Problem here! Overwrites offset 0x38 as well
-
-After the first strb instruction, which writes to 0x10009038, everything is fine. It can be seen in the QEMU monitor:
-
-(qemu) xp 0x10009038
-0000000010009038: 0x00000010
-
-After the second strb instruction, the write to 0x10009039 clears the entire word:
-
-(qemu) xp 0x10009038
-0000000010009038: 0x00000000
-
-QEMU command-line, using the vexpress-a9 which has the PL011 at 0x10009000:
-
-qemu-system-arm -S -M vexpress-a9 -m 32M -no-reboot -nographic -monitor telnet:127.0.0.1:1234,server,nowait -kernel pl011-sfr.bin -gdb tcp::2159 -serial mon:stdio
-
-Compiling the original C code with optimizations makes the driver work. It compiles down to assembly that only does a single write:
-
-    ldr r3, pl011_addr
-    mov r2, #0x10
-    str r2, [r3, #0x38]
-
-Attached is the an assembly file, and linkscript, that shows the problem, and also includes the working code.
-
-I haven't debugged inside of QEMU itself but it seems to me that the problem is in pl011_write in pl011.c - the functions looks at which offset is being written, and then writes the entire SFR that offset falls under, which means that changing a single byte will change the whole SFR.
-
-
-
-Adding the link script.
-
-Yes, our PL011 implementation assumes that you only ever access the 32-bit registers with full width 32-bit word reads and writes. Don't try to do byte accesses to them. The PL011 data sheet doesn't specifically say that partial-width accesses to registers are permitted, so I think that trying to access offset 0x39 falls under the general note in section 3.1 that attempting to access reserved or unused address locations can result in unpredictable behaviour.
-
-You need to make sure you write your C code in a manner which enforces that accesses to device registers are done as single 32-bit accesses, and the compiler does not silently break them down into multiple reads and writes, or you will be in for a lot of pain trying to figure out what is going on if the compiler ever does it with registers that are write-to-clear or similar behaviour. Linux, for instance, does this by having readl() and writel() functions that end up doing inline asm of ldr/str instructions.
-
-
-Thanks for the response.
-
-I don't think section 3.1 applies to 8-bit accesses. That is specifically about reserved locations, and neither offset 0x38 nor 0x39 are reserved, so I think it's a matter of whether 32-bit access is required or not.
-
-From what I usually see in ARM documentation, 32-bit access is explicitly mentioned when required. For the PL011, it's mentioned for the UARTPeriphID_n registers, for instance. In many other cases access size depends on the implementation and the corresponding memory mapping of that implementation.
-
-I understand that *in practice* you should ensure single-access writes unless doing otherwise is explicitly allowed. However, in cases like the PL011 it seems ambiguous whether that is actually required, so it seems like the best choice would be to explicitly document it for the QEMU implementation. That would save some guesswork.
-
-The QEMU project is currently considering to move its bug tracking to
-another system. For this we need to know which bugs are still valid
-and which could be closed already. Thus we are setting older bugs to
-"Incomplete" now.
-
-If you still think this bug report here is valid, then please switch
-the state back to "New" within the next 60 days, otherwise this report
-will be marked as "Expired". Or please mark it as "Fix Released" if
-the problem has been solved with a newer version of QEMU already.
-
-Thank you and sorry for the inconvenience.
-
-
-[Expired for QEMU because there has been no activity for 60 days.]
-
diff --git a/results/classifier/semantic-bugs/semantic/1923197 b/results/classifier/semantic-bugs/semantic/1923197
deleted file mode 100644
index 06e79479..00000000
--- a/results/classifier/semantic-bugs/semantic/1923197
+++ /dev/null
@@ -1,149 +0,0 @@
-semantic: 0.907
-mistranslation: 0.879
-other: 0.869
-assembly: 0.855
-instruction: 0.854
-socket: 0.832
-device: 0.813
-graphic: 0.805
-KVM: 0.794
-vnc: 0.737
-boot: 0.724
-network: 0.710
-
-RISC-V priviledged instruction error
-
-Hello when performing an MRET with MPP set to something else than 0b11 in MSTATUS, 'Invalid Instruction' exception will be triggered. The problem appeared in code after version 5.2.0.
-
-<pre>
-  # setup interrupt handling for monitor mode
-  la t0, entry_loop
-  la t1, entry_trap
-  li t2, 0x888
-  li t3, 0x1880 # MPP in MSTATUS selects to which mode to return & MPIE selects if to enable interrupts after MRET
-  csrw mepc, t0
-  csrw mtvec, t1
-  csrs mie, t2
-  csrs mstatus, t3
-
-  # if supervisor mode not supported, then loop forever
-  csrr t0, misa
-  li t1, 0x40000
-  and t2, t1, t0
-  beqz t2, 1f
-
-  # setup interrupt i& exception delegation for supervisor mode
-  li t0, 0xc0000000 # 3 GiB (entry address of supervisor)
-  li t1, 0x1000
-  #li t2, 0x300 # bit 8 & 9 is for ecall from user & supervisor mode
-  #li t3, 0x222
-  csrw mepc, t0
-  csrc mstatus, t1
-  #csrs medeleg, t2
-  #csrs mideleg, t3
-
-  # pass mhartid as first parameter to supervisor
-  csrr a0, mhartid
-
-1:
-  mret
-</pre>
-
-I'm guessing that this is a bug in your guest as it hasn't configured PMP regions.
-
-From the RISC-V spec:
-
-"
-If no PMP entry matches an M-mode access, the access succeeds. If no PMP entry matches an
-S-mode or U-mode access, but at least one PMP entry is implemented, the access fails.
-"
-
-Confusingly implemented here means implemented in hardware, not just configured.
-
-You can check this by reverting this QEMU commit:
-
-commit d102f19a2085ac931cb998e6153b73248cca49f1
-Author: Atish Patra <email address hidden>
-Date:   Wed Dec 23 11:25:53 2020 -0800
-
-    target/riscv/pmp: Raise exception if no PMP entry is configured
-    
-    As per the privilege specification, any access from S/U mode should fail
-    if no pmp region is configured.
-    
-    Signed-off-by: Atish Patra <email address hidden>
-    Reviewed-by: Alistair Francis <email address hidden>
-    Message-id: <email address hidden>
-    Signed-off-by: Alistair Francis <email address hidden>
-
-
-Hello Francis,
-
-I'll configure PMP than do the test again. Sorry I hadn't understood what
-changed between version 5.2 and 6.0-rc2, since my code worked before.
-
-Best regards,
-Teodori Serge
-
-On Thu, 15 Apr 2021, 06:15 Alistair Francis, <email address hidden>
-wrote:
-
-> I'm guessing that this is a bug in your guest as it hasn't configured
-> PMP regions.
->
-> >From the RISC-V spec:
->
-> "
-> If no PMP entry matches an M-mode access, the access succeeds. If no PMP
-> entry matches an
-> S-mode or U-mode access, but at least one PMP entry is implemented, the
-> access fails.
-> "
->
-> Confusingly implemented here means implemented in hardware, not just
-> configured.
->
-> ** Changed in: qemu
->        Status: Confirmed => Invalid
->
-> --
-> You received this bug notification because you are subscribed to the bug
-> report.
-> https://bugs.launchpad.net/bugs/1923197
->
-> Title:
->   RISC-V priviledged instruction error
->
-> To manage notifications about this bug go to:
-> https://bugs.launchpad.net/qemu/+bug/1923197/+subscriptions
->
-
-
-We fixed a bug to make QEMU act more like hardware, which now means that PMP must be configured in M-mode.
-
-Hello Francis,
-
-Yes thank you. I added code to setup a basic PMP and it works now. Thank
-you and best regards,
-
-Teodori Serge
-
-On Sun, 18 Apr 2021, 05:55 Alistair Francis, <email address hidden>
-wrote:
-
-> We fixed a bug to make QEMU act more like hardware, which now means that
-> PMP must be configured in M-mode.
->
-> --
-> You received this bug notification because you are subscribed to the bug
-> report.
-> https://bugs.launchpad.net/bugs/1923197
->
-> Title:
->   RISC-V priviledged instruction error
->
-> To manage notifications about this bug go to:
-> https://bugs.launchpad.net/qemu/+bug/1923197/+subscriptions
->
-
-
-- 
cgit v1.2.3