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
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
|
architecture: 0.913
performance: 0.911
semantic: 0.910
user-level: 0.902
device: 0.898
permissions: 0.898
PID: 0.889
graphic: 0.889
ppc: 0.888
mistranslation: 0.885
virtual: 0.883
arm: 0.881
debug: 0.880
register: 0.879
assembly: 0.876
hypervisor: 0.869
kernel: 0.868
peripherals: 0.865
VMM: 0.860
TCG: 0.855
risc-v: 0.855
vnc: 0.850
boot: 0.843
KVM: 0.842
socket: 0.841
files: 0.840
network: 0.837
x86: 0.744
i386: 0.626
aarch64-softmmu "bad ram pointer" crash
I am developing a piece of software called SimBench which is a benchmarking system for full system simulators. I am currently porting this to aarch64, using QEMU as a test platform.
I have encountered a 'bad ram pointer' crash. I've attempted to build a minimum test case, but I haven't managed to replicate the behaviour in isolation, so I've created a branch of my project which exhibits the crash: https://bitbucket.org/Awesomeclaw/simbench/get/qemu-bug.tar.gz
The package can be compiled using:
make
and then run using:
qemu-system-aarch64 -M virt -m 512 -cpu cortex-a57 -kernel out/armv8/virt/simbench -nographic
I have replicated the issue in both qemu 2.8.1 and in 2.9.0-rc3, on Fedora 23. Please let me know if you need any more information or any logs/core dumps/etc.
I've done some investigation and it appears that this bug is caused by the following:
1. The flash memory of the virt platform is initialised as a cfi.pflash01. It has a memory region with romd_mode = true and rom_device = true
2. Some code stored in the flash memory is executed. This causes the memory to be loaded into the TLB.
3. The code is overwritten. This causes the romd_mode of the flash memory to be reset. It also causes the code to be evicted from the TLB.
4. An attempt is made to execute the code again (cpu_exec(), cpu-exec.c:677)
4a. Eventually, QEMU attempts to refill the TLB (softmmu_template.h:127)
4b. We try to fill in the tlb entry (tlb_set_page_with_attrs, cputlb.c:602)
4b. The flash memory no longer appears to be a ram or romd (cputlb.c:632)
4c. QEMU decides that the flash memory is an IO device (cputlb.c:634)
4d. QEMU aborts while trying to fill in the rest of the TLB entry (qemu_ram_addr_from_host_nofail)
I have built a MWE (which I have attached) which produces this behaviour in git head. I'm not exactly sure what a fix for this should look like: AFAIK it's not technically valid to write into flash, but I'm not sure that QEMU crashing should be considered correct behaviour.
On 12 April 2017 at 16:02, Harry Wagstaff <email address hidden> wrote:
> I've done some investigation and it appears that this bug is caused by
> the following:
>
> 1. The flash memory of the virt platform is initialised as a
> cfi.pflash01. It has a memory region with romd_mode = true and
> rom_device = true
>
> 2. Some code stored in the flash memory is executed. This causes the
> memory to be loaded into the TLB.
>
> 3. The code is overwritten. This causes the romd_mode of the flash
> memory to be reset. It also causes the code to be evicted from the TLB.
>
> 4. An attempt is made to execute the code again (cpu_exec(), cpu-exec.c:677)
> 4a. Eventually, QEMU attempts to refill the TLB (softmmu_template.h:127)
> 4b. We try to fill in the tlb entry (tlb_set_page_with_attrs, cputlb.c:602)
> 4b. The flash memory no longer appears to be a ram or romd (cputlb.c:632)
> 4c. QEMU decides that the flash memory is an IO device (cputlb.c:634)
> 4d. QEMU aborts while trying to fill in the rest of the TLB entry (qemu_ram_addr_from_host_nofail)
Yeah, this is a known bug -- but fixing it would just mean that
we would print the slightly more helpful message about the
guest attempting to execute from something that isn't RAM
or ROM before exiting.
See for instance this thread from January.
https://lists.nongnu.org/archive/html/qemu-devel/2017-01/msg00674.html
> I have built a MWE (which I have attached) which produces this behaviour
> in git head. I'm not exactly sure what a fix for this should look like:
> AFAIK it's not technically valid to write into flash, but I'm not sure
> that QEMU crashing should be considered correct behaviour.
You should fix your guest so that it doesn't try to execute
from flash without putting the flash back into the mode you
can execute from...
Writing to the flash device is permitted -- it's how
you program it (you write command bytes to it, and
read back responses and status and so on).
thanks
-- PMM
|