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
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
|
boot: 0.928
device: 0.909
assembly: 0.902
vnc: 0.894
other: 0.890
graphic: 0.888
instruction: 0.867
mistranslation: 0.865
socket: 0.859
semantic: 0.857
network: 0.834
KVM: 0.827
qemu 1.1.0 waits for a keypress at boot
qemu 1.1.0 waits for a keypress at boot. Please don't ever do this.
Try the attached test script. When run it will initially print nothing, until you hit a key on the keyboard.
Removing -nographic fixes the problem.
Using virtio-scsi instead of virtio-blk fixes the problem.
Also affects upstream qemu from git.
Using -device sga fixes the problem, but also means I cannot see what it's trying to wait for.
I don't see this problem. Are you sure you're not using the bios from Fedora? Perhaps it's configured incorrectly.
Yes, I tested it again and it does look like it's loading a Fedora ROM. Dammit ...
This is a bit more interesting. I've got a bugreport in debian about the same thing, and verified it in debian qemu-kvm package - indeed, with -nographics, upstream 1.1 qemu and qemu-kvm refuses to boot without an extra keypress, but only when kernel_irqchip is enabled. Ie, the following requires keypress:
qemu -machine pc,accel=kvm,kernel_irqchip=on -nographics
qemu-kvm -nographics
and the following does not:
qemu -machine pc,accel=kvm -nographics
qemu-kvm -no-kvm-irqchip -nographics
Thanks,
/mjt
Well that's very interesting because one of the patches we have added in Fedora is:
http://pkgs.fedoraproject.org/gitweb/?p=qemu.git;a=blob;f=0001-qemu-kvm-Add-missing-default-machine-options.patch;h=e785a708d0bf0861c2f0f1777b8cc477d12fe145;hb=HEAD
when the guest is waiting for the keypress, it is sitting in KVM_RUN ioctl and eating 100% CPU. When enabling Seabios debugging, the last lines before the stall is this:
Returned 57344 bytes of ZoneHigh
e820 map has 7 items:
0: 0000000000000000 - 000000000009dc00 = 1 RAM
1: 000000000009dc00 - 00000000000a0000 = 2 RESERVED
2: 00000000000f0000 - 0000000000100000 = 2 RESERVED
3: 0000000000100000 - 000000001fffe000 = 1 RAM
4: 000000001fffe000 - 0000000020000000 = 2 RESERVED
5: 00000000feffc000 - 00000000ff000000 = 2 RESERVED
6: 00000000fffc0000 - 0000000100000000 = 2 RESERVED
enter handle_19:
NULL
Booting from Hard Disk...
_
So far it only happens when "booting" from a VIRTIO hard disk. With IDE disk it boots fine.
So, in order for it to actually stall,
qemu -machine pc,accel=kvm,kernel_irqchip=on -drive file=foo,if=virtio -nographics
is needed.
Thanks,
/mjt
Jamie Heilman (the debian bug #680719 reporter) bisected this issue to this commit:
7c7db75576bd5a31508208f153c5aada64b2c8df is the first bad commit
commit 7c7db75576bd5a31508208f153c5aada64b2c8df
Author: Stefano Stabellini <email address hidden>
Date: Fri Apr 13 19:35:04 2012 +0100
main_loop_wait: block indefinitely
- remove qemu_calculate_timeout;
- explicitly size timeout to uint32_t;
- introduce slirp_update_timeout;
- pass NULL as timeout argument to select in case timeout is the maximum
value;
Signed-off-by: Stefano Stabellini <email address hidden>
Acked-by: Paul Brook <email address hidden>
Signed-off-by: Anthony Liguori <email address hidden>
I encountered the same thing and created a patch that fixes the problem for me.
This is not a real fix. All i have done is the following:
- Clone the repo.
- Get a reverse diff for the commit in question "git diff 7c7db75..4ffd16f >foo1.patch".
- Try to apply this on master "patch <foo1.patch" and skip all files that could not be found.
- And finally do a "git diff >remove-7c7db75.patch"
As i am a gentoo user i applied this patch within my ebuild and
This is definitely a wrong way to "fix" this issue.
The patch at http://permalink.gmane.org/gmane.comp.emulators.qemu/162828 fixes it for ioeventfd=on (the bug is that the ioeventfd is not added to the select() arguments), but I and Avi disagreed on whether ioeventfd=off works. :)
Jamie/Richard/Georg, can you test your respective reproducers without any patch but with -global virtio-blk-pci.ioeventfd=off?
Can this issue still be reproduced with the latest version of QEMU, or can we close this bug nowadays?
No this refers to a very old version of qemu. This bug should be closed.
|