Bug 791200

Summary:	Character device consumers can miss OPENED events
Product:	Red Hat Enterprise Linux 6	Reporter:	Stefan Hajnoczi <stefanha>
Component:	qemu-kvm	Assignee:	Kevin Wolf <kwolf>
Status:	CLOSED ERRATA	QA Contact:	Virtualization Bugs <virt-bugs>
Severity:	high	Docs Contact:
Priority:	unspecified
Version:	6.3	CC:	acathrow, bsarathy, chayang, juzhang, kwolf, michen, minovotn, mkenneth, rjones, shu, tzheng, virt-maint, xfu, yhalperi
Target Milestone:	rc
Target Release:	---
Hardware:	x86_64
OS:	Linux
Whiteboard:
Fixed In Version:	qemu-kvm-0.12.1.2-2.234.el6	Doc Type:	Bug Fix
Doc Text:	No Documentation Needed	Story Points:	---
Clone Of:		Environment:
Last Closed:	2012-06-20 11:43:32 UTC	Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:

Description Stefan Hajnoczi 2012-02-16 13:42:06 UTC

Description of problem:

QEMU character devices emit an OPENED event when the device is open or a connection has been accepted.  This is used, for example, to print the QMP monitor greeting.

Because character devices are initialized in vl.c:main() before their consumers care must be taken to deliver the OPENED event reliably.

In Kevin's coroutine backport to RHEL 6.3 I noticed that the QMP monitor does not work on a socket,path=/tmp/qemu-mon UNIX domain socket because the OPENED event is emitted before the QMP monitor is attached.  As a result, the QMP monitor never begins operation and clients do not see the greeting.

Alexander Graf fixed this issue for a different scenario with the s390 virtio-console.  His patch also addresses RHEL 6.3 qemu-kvm with coroutines in the block layer.

Version-Release number of selected component (if applicable):

RHEL 6.3 qemu-kvm with Kevin's coroutines backport series

How reproducible:

Deterministic

Steps to Reproduce:
1. nc -l -U /tmp/qemu-mon
2. In another shell: x86_64-softmmu/qemu-system-x86_64 -cpu host -chardev socket,id=mon,path=/tmp/qemu-mon -mon chardev=mon,mode=control -nographic -drive if=virtio,file=test.img,cache=none,id=virtio0
  
Actual results:

The netcat sessions never receives the QMP monitor greeting.

Expected results:

The QMP monitor should send the greeting to the netcat client.

Additional info:

Please cherry-pick Alexander Graf's fix 73cdf3f2c97703a89b026d3a42c1120ba05fe37d.

Comment 1 Kevin Wolf 2012-02-21 09:10:10 UTC

*** Bug 795661 has been marked as a duplicate of this bug. ***

Comment 4 Qixiang Wan 2012-02-29 02:16:30 UTC

*** Bug 796115 has been marked as a duplicate of this bug. ***

Comment 5 Chao Yang 2012-03-02 03:16:27 UTC

--- Reproduced this bug with qemu-kvm-0.12.1.2-2.233.el6.x86_64.
Scenario 1:
1. listen by nc -lU /path/to/unix-socket
2. boot a guest by two ways:
a. -chardev socket,id=mon,path=/opt/mon.monitor -mon chardev=mon,mode=control
b. -qmp unix:/opt/mon.monitor 

Actual Result:
No greeting printed.
# nc -lU /opt/mon.monitor
{"execute":"qmp_capabilities"}   <--- returns nothing

Scenario 2:
1. listen by nc -lU /path/to/unix-socket
2. boot a guest by -monitor stdio

Actual Result:
No greeting printed like "QEMU 0.12.1 monitor - type 'help' for more information
"

--- Verified with qemu-kvm-0.12.1.2-2.234.el6.x86_64 using same scenarios above.
Scenario 1 actual result:
Greeting printed.
# nc -lU /opt/mon.monitor
 {"QMP": {"version": {"qemu": {"micro": 1, "minor": 12, "major": 0}, "package": "(qemu-kvm-0.12.1.2)"}, "capabilities": []}}
 {"execute":"qmp_capabilities"}
 {"return": {}}

Scenario 2 actual result:
Greeting printed in screen:
QEMU 0.12.1 monitor - type 'help' for more information


--- As per above, this issue has been fixed.

Comment 7 Amit Shah 2012-04-11 08:19:33 UTC

*** Bug 796203 has been marked as a duplicate of this bug. ***

Comment 9 Michal Novotny 2012-05-04 12:43:08 UTC

    Technical note added. If any revisions are required, please edit the "Technical Notes" field
    accordingly. All revisions will be proofread by the Engineering Content Services team.
    
    New Contents:
NEEDINFO

Comment 12 Richard W.M. Jones 2012-05-08 10:52:07 UTC

    Technical note updated. If any revisions are required, please edit the "Technical Notes" field
    accordingly. All revisions will be proofread by the Engineering Content Services team.
    
    Diffed Contents:
@@ -1 +1 @@
-NEEDINFO+No Documentation Needed

Comment 13 errata-xmlrpc 2012-06-20 11:43:32 UTC

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

http://rhn.redhat.com/errata/RHBA-2012-0746.html