blob: df1442bc74f5c46ca584a1f8b02b0cf4eb8e4a6c (
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
|
KVM: 0.966
socket: 0.940
performance: 0.830
device: 0.806
semantic: 0.731
graphic: 0.726
debug: 0.726
ppc: 0.718
kernel: 0.649
user-level: 0.575
network: 0.541
architecture: 0.500
x86: 0.482
virtual: 0.479
arm: 0.458
permissions: 0.426
hypervisor: 0.417
mistranslation: 0.401
i386: 0.396
vnc: 0.391
register: 0.382
peripherals: 0.364
boot: 0.326
risc-v: 0.324
PID: 0.310
assembly: 0.291
files: 0.195
TCG: 0.175
VMM: 0.172
not receiving RESET event after system_reset command causes QMP connection to die
I have written my own implementation to control machine running KVM instances with the QMP protocol. Its a pretty basic implementation that sends/receives in the same thread. This means that all of the events QEMU sents are received only when the application expects a reply from a command. In the following scenario, i'm unable to (re)connect to the QMP socket from QEMU after I closed the connection:
1) Connect to QMP
2) Sent qmp_capabilities
3) Receive reply
4) Send system_reset
5) Receive reply
6) close socket
7) Connect to socket -> connection refused
However, in the following scenario, I am able to connect after I disconnect the socket because I have read the two RESET events:
1) Connect to QMP
2) Sent qmp_capabilities
3) Receive reply
4) Send system_reset
5) Receive reply
6) Receive reply (is a RESET event)
7) Receive reply (is a RESET event)
8) close socket
9) Connect to socket -> ok
I don't know if this is a bug or expected behavior. I can't find any proper way to disconnect the socket documentated. Am I doïng something wrong, or is this a bug in the QMP implementation of QEMU?
For what its worth, i'm using Ubuntu 12.10:
kvm --version
QEMU emulator version 1.2.0 (qemu-kvm-1.2.0+noroms-0ubuntu2.12.10.3, Debian), Copyright (c) 2003-2008 Fabrice Bellard
Triaging old bug tickets... can you still reproduce this issue with the latest version of QEMU? Or could we close this ticket nowadays?
I'm not sure, the current implementation is multi-threaded so I won't hit this bug if its still present. If I can find the time I will make a proof of concept and test if the bug is still present.
[Expired for QEMU because there has been no activity for 60 days.]
|