1 files changed, 36 insertions, 0 deletions
diff --git a/results/classifier/deepseek-r1:14b/output/hypervisor/1556 b/results/classifier/deepseek-r1:14b/output/hypervisor/1556
new file mode 100644
index 00000000..0e48bfca
--- /dev/null
+++ b/results/classifier/deepseek-r1:14b/output/hypervisor/1556
@@ -0,0 +1,36 @@
+
+RISCV HGATP CSR writes incorrect
+Description of problem:
+Issue with CSR writes/reads of SATP and HGATP. 
+Starting with SATP, in file `qemu/target/riscv/csr.c` the function write_satp has the following code snippet:
+
+```C
+    if (riscv_cpu_mxl(env) == MXL_RV32) {
+        vm = validate_vm(env, get_field(val, SATP32_MODE));
+        mask = (val ^ env->satp) & (SATP32_MODE | SATP32_ASID | SATP32_PPN);
+    } else {
+        vm = validate_vm(env, get_field(val, SATP64_MODE));
+        mask = (val ^ env->satp) & (SATP64_MODE | SATP64_ASID | SATP64_PPN);
+    }
+
+    if (vm && mask) {
+        if (env->priv == PRV_S && get_field(env->mstatus, MSTATUS_TVM)) {
+            return RISCV_EXCP_ILLEGAL_INST;
+```
+The potential problem I see in the code is that a CSR write which is either illegal or the same as what was previously in the CSR will not yield an illegal instruction. This potential issue could be simple to fix by simply moving the TVM check outside the vm && mask if-statement.
+EDIT: I haven't been able to replicate this. Maybe there is code somewhere else which guards against this situation, I'll leave this comment here anyway just to get an extra pair of eyes on this code.
+
+For writes to hgatp (in the same source file) the value provided to the function is simply written directly to hgatp.
+```
+static RISCVException write_hgatp(CPURISCVState *env, int csrno,
+                                  target_ulong val)
+{
+    env->hgatp = val;
+    return RISCV_EXCP_NONE;
+}
+```
+This can not be correct, the specification for example states `"A write to hgatp with an unsupported MODE value is not ignored as it is for satp. Instead, the fields of hgatp are WARL in the normal way, when so indicated."` Furthermore, there is also a restriction on the ppn field saying that ppn[1:0] must be 0. Finally when reading hgatp the tvm flag is not taken into consideration at all.
+Additional information:
+The provided binary should be able to replicate the issue. The error regarding num_unexp_trap can be disregarded in this case, normally I break a test directly on an assertion failure but I didn't this time which is why the counter is increasing.
+
+[main](/uploads/31ef3bc424d63097177cba3579d9b411/main)