1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
|
graphic: 0.842
architecture: 0.789
performance: 0.769
ppc: 0.759
peripherals: 0.745
device: 0.730
hypervisor: 0.682
files: 0.655
mistranslation: 0.568
permissions: 0.537
boot: 0.528
risc-v: 0.517
semantic: 0.502
kernel: 0.500
vnc: 0.496
network: 0.476
PID: 0.473
socket: 0.454
debug: 0.404
user-level: 0.403
VMM: 0.375
arm: 0.371
register: 0.282
TCG: 0.234
virtual: 0.201
x86: 0.179
KVM: 0.145
assembly: 0.136
i386: 0.089
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)
|
