diff options
Diffstat (limited to 'results/classifier/105/KVM/1156632')
| -rw-r--r-- | results/classifier/105/KVM/1156632 | 49 |
1 files changed, 49 insertions, 0 deletions
diff --git a/results/classifier/105/KVM/1156632 b/results/classifier/105/KVM/1156632 new file mode 100644 index 000000000..da5d8f4a3 --- /dev/null +++ b/results/classifier/105/KVM/1156632 @@ -0,0 +1,49 @@ +KVM: 0.966 +socket: 0.940 +device: 0.806 +semantic: 0.731 +graphic: 0.726 +instruction: 0.711 +other: 0.693 +network: 0.541 +mistranslation: 0.401 +vnc: 0.391 +boot: 0.326 +assembly: 0.291 + +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.] + |