blob: 40670f3a04d0e77256a1ae7dc3dcc7724d4dc7a4 (
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
|
graphic: 0.777
boot: 0.619
network: 0.598
device: 0.570
vnc: 0.533
socket: 0.530
instruction: 0.521
other: 0.456
semantic: 0.441
KVM: 0.381
mistranslation: 0.341
assembly: 0.243
large -initrd can wrap around in memory causing memory corruption
We don't use large -initrd in libguestfs any more, but I noticed that a large -initrd file now crashes qemu spectacularly:
$ ls -lh /tmp/kernel /tmp/initrd
-rw-r--r--. 1 rjones rjones 273M Jun 3 14:02 /tmp/initrd
lrwxrwxrwx. 1 rjones rjones 35 Jun 3 14:02 /tmp/kernel -> /boot/vmlinuz-3.9.4-200.fc18.x86_64
$ ./x86_64-softmmu/qemu-system-x86_64 -L pc-bios \
-kernel /tmp/kernel -initrd /tmp/initrd -hda /tmp/test1.img -serial stdio \
-append console=ttyS0
qemu crashes with one of several errors:
PFLASH: Possible BUG - Write block confirm
qemu: fatal: Trying to execute code outside RAM or ROM at 0x00000000000b96cd
If -enable-kvm is used:
KVM: injection failed, MSI lost (Operation not permitted)
In all cases the SDL display fills up with coloured blocks before the crash (see the attached screenshot).
I'm using qemu from git (f10acc8b38d65a66ffa0588a036489d7fa6a593e).
One way to reproduce this is to just use a large (200 MB) completely random initrd. Note this error seems to happen a long time before even the kernel starts up, so the actual content of the initrd doesn't matter.
dd if=/dev/urandom of=/tmp/initrd bs=1M count=200
qemu-system-x86_64 -kernel /boot/vmlinuz -initrd /tmp/initrd -serial stdio -append console=ttyS0
OK I see what's happening. Because I forgot about the -m option, qemu allocates 128 MB of RAM. It's obviously wrapping around in memory and overwriting all the low memory.
If you add (eg) -m 1024 it works.
Just saw something similar with qemu 2.2.1:
KVM: injection failed, MSI lost (Input/output error)
qemu-system-x86_64: /home/bart/software/qemu-2.2.1/hw/net/vhost_net.c:264: vhost_net_stop_one: Assertion `r >= 0' failed.
2015-03-23 02:44:44.952+0000: shutting down
Although the error message is the same, the bug in comment 5 seems completely different. Please open a new bug about this issue, giving *all* details - including the full qemu command line.
Thanks Richard for the quick feedback. A new bug report has been created as https://bugs.launchpad.net/qemu/+bug/1435359.
Triaging old bug tickets... can you still reproduce this issue with the latest version of QEMU? Or could we close this ticket nowadays?
The answer is I don't know. Closing this bug seems correct unless someone can reproduce the original problem.
[Expired for QEMU because there has been no activity for 60 days.]
|