blob: c487cb658de69bfe693b90cfb381a72361f4a69c (
plain) (
blame)
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
66
67
68
69
70
71
72
73
74
|
architecture: 0.952
risc-v: 0.916
assembly: 0.781
graphic: 0.759
performance: 0.649
device: 0.634
semantic: 0.632
mistranslation: 0.442
permissions: 0.288
vnc: 0.284
debug: 0.274
register: 0.245
virtual: 0.240
user-level: 0.209
ppc: 0.207
network: 0.181
peripherals: 0.174
arm: 0.148
boot: 0.140
PID: 0.138
kernel: 0.133
socket: 0.116
x86: 0.109
TCG: 0.107
VMM: 0.089
files: 0.081
hypervisor: 0.070
i386: 0.054
KVM: 0.044
--------------------
risc-v: 0.998
debug: 0.831
virtual: 0.450
performance: 0.070
register: 0.067
assembly: 0.067
architecture: 0.021
hypervisor: 0.020
boot: 0.015
semantic: 0.005
TCG: 0.004
PID: 0.004
files: 0.003
user-level: 0.003
kernel: 0.002
device: 0.002
socket: 0.001
KVM: 0.001
network: 0.001
graphic: 0.001
permissions: 0.001
VMM: 0.000
peripherals: 0.000
vnc: 0.000
mistranslation: 0.000
arm: 0.000
x86: 0.000
i386: 0.000
ppc: 0.000
RISC-V 64, CPUs do ilegal 0x00 write with SMP
When QEMU is runt like this:
qemu-system-riscv64 -d unimp,guest_errors -smp 8
Other harts will do a illegal write on address 0x00.
This could be mostly (i think) because the initial assembly code is only loaded on the first hart and the others do a mess because there is no code to execute.
Even with -smp 1 you will see the same errors. The problem is because there is nothing to run after OpenSBI jumps to the next stage.
If you load a kernel you will not see the error messages.
|