* [Qemu-devel] QMP event missed during startup
@ 2017-10-30 10:50 Ross Lagerwall
2017-10-30 17:18 ` Dr. David Alan Gilbert
0 siblings, 1 reply; 4+ messages in thread
From: Ross Lagerwall @ 2017-10-30 10:50 UTC (permalink / raw)
To: qemu-devel; +Cc: Markus Armbruster
Hi,
I have found an issue where QEMU emits the RESUME event during startup
when it starts VM execution, but it is not possible to receive this event.
To repro this, run:
qemu-system-i386 -m 256 -trace
enable=monitor_protocol_event_emit,file=/tmp/out -qmp
unix:/tmp/qmp,server,wait
QEMU will not start execution of the VM until something connects to the
QMP socket (e.g. qmp-shell). Once connected, no event is received on the
QMP connection but the tracepoint is hit indicating that an event has
been emitted. I suspect that the event is emitted while the QMP client
is doing the initial negotiation.
The reason I want to receive this event is that QEMU currently uses
xenstore to communicate this information to the Xen toolstack (see
xen-common.c:xen_change_state_handler) but we want to move to using QMP
rather than xenstore for this kind of thing.
Is this a known issue or just a bug that should be fixed?
Thanks,
--
Ross Lagerwall
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [Qemu-devel] QMP event missed during startup
2017-10-30 10:50 [Qemu-devel] QMP event missed during startup Ross Lagerwall
@ 2017-10-30 17:18 ` Dr. David Alan Gilbert
2017-11-09 14:14 ` Markus Armbruster
0 siblings, 1 reply; 4+ messages in thread
From: Dr. David Alan Gilbert @ 2017-10-30 17:18 UTC (permalink / raw)
To: Ross Lagerwall; +Cc: qemu-devel, Markus Armbruster
* Ross Lagerwall (ross.lagerwall@citrix.com) wrote:
> Hi,
>
> I have found an issue where QEMU emits the RESUME event during startup when
> it starts VM execution, but it is not possible to receive this event.
>
> To repro this, run:
> qemu-system-i386 -m 256 -trace
> enable=monitor_protocol_event_emit,file=/tmp/out -qmp
> unix:/tmp/qmp,server,wait
>
> QEMU will not start execution of the VM until something connects to the QMP
> socket (e.g. qmp-shell). Once connected, no event is received on the QMP
> connection but the tracepoint is hit indicating that an event has been
> emitted. I suspect that the event is emitted while the QMP client is doing
> the initial negotiation.
>
> The reason I want to receive this event is that QEMU currently uses xenstore
> to communicate this information to the Xen toolstack (see
> xen-common.c:xen_change_state_handler) but we want to move to using QMP
> rather than xenstore for this kind of thing.
>
> Is this a known issue or just a bug that should be fixed?
I'll leave it to Markus to say if it's a bug or not, but can't
you work around this by starting qemu with -S which leaves the guest
paused, and then continuing the guest when you have your QMP ?
Dave
> Thanks,
> --
> Ross Lagerwall
>
--
Dr. David Alan Gilbert / dgilbert@redhat.com / Manchester, UK
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [Qemu-devel] QMP event missed during startup
2017-10-30 17:18 ` Dr. David Alan Gilbert
@ 2017-11-09 14:14 ` Markus Armbruster
2017-11-10 10:43 ` Ross Lagerwall
0 siblings, 1 reply; 4+ messages in thread
From: Markus Armbruster @ 2017-11-09 14:14 UTC (permalink / raw)
To: Dr. David Alan Gilbert; +Cc: Ross Lagerwall, qemu-devel
"Dr. David Alan Gilbert" <dgilbert@redhat.com> writes:
> * Ross Lagerwall (ross.lagerwall@citrix.com) wrote:
>> Hi,
>>
>> I have found an issue where QEMU emits the RESUME event during startup when
>> it starts VM execution, but it is not possible to receive this event.
>>
>> To repro this, run:
>> qemu-system-i386 -m 256 -trace
>> enable=monitor_protocol_event_emit,file=/tmp/out -qmp
>> unix:/tmp/qmp,server,wait
>>
>> QEMU will not start execution of the VM until something connects to the QMP
>> socket (e.g. qmp-shell). Once connected, no event is received on the QMP
>> connection but the tracepoint is hit indicating that an event has been
>> emitted. I suspect that the event is emitted while the QMP client is doing
>> the initial negotiation.
>>
>> The reason I want to receive this event is that QEMU currently uses xenstore
>> to communicate this information to the Xen toolstack (see
>> xen-common.c:xen_change_state_handler) but we want to move to using QMP
>> rather than xenstore for this kind of thing.
>>
>> Is this a known issue or just a bug that should be fixed?
>
> I'll leave it to Markus to say if it's a bug or not, but can't
> you work around this by starting qemu with -S which leaves the guest
> paused, and then continuing the guest when you have your QMP ?
You can:
<-- {"QMP": {"version": {"qemu": {"micro": 50, "minor": 10, "major": 2}, "package": " (v2.10.0-613-g10656079e1-dirty)"}, "capabilities": []}}
--> { "execute": "qmp_capabilities" }
<-- {"return": {}}
--> { "execute": "cont" }
<-- {"timestamp": {"seconds": 1510235984, "microseconds": 108550}, "event": "RESUME"}
<-- {"return": {}}
RESUME is sent in vm_prepare_start(), called from main() via vm_start(),
but only if @autostart, i.e. no -S.
The "wait" in the argument of -qmp makes QEMU wait for a QMP client to
connect to the QMP socket, long before vm_start() gets called. However,
having connected is not sufficient for receiving events, you also have
to exit capabilities negotiation mode. Not possible until QEMU is
running the main loop, which runs after the vm_start() quoted above.
If QMP monitors became usable before entering main_loop(), we'd have a
race condition instead. The only reliable way to get the RESUME event
is -S.
This adds one minor item to the long list of reasons why management
software should pass -S.
All clear now?
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [Qemu-devel] QMP event missed during startup
2017-11-09 14:14 ` Markus Armbruster
@ 2017-11-10 10:43 ` Ross Lagerwall
0 siblings, 0 replies; 4+ messages in thread
From: Ross Lagerwall @ 2017-11-10 10:43 UTC (permalink / raw)
To: Markus Armbruster, Dr. David Alan Gilbert; +Cc: qemu-devel
On 11/09/2017 02:14 PM, Markus Armbruster wrote:
> "Dr. David Alan Gilbert" <dgilbert@redhat.com> writes:
>
>> * Ross Lagerwall (ross.lagerwall@citrix.com) wrote:
>>> Hi,
>>>
>>> I have found an issue where QEMU emits the RESUME event during startup when
>>> it starts VM execution, but it is not possible to receive this event.
>>>
>>> To repro this, run:
>>> qemu-system-i386 -m 256 -trace
>>> enable=monitor_protocol_event_emit,file=/tmp/out -qmp
>>> unix:/tmp/qmp,server,wait
>>>
>>> QEMU will not start execution of the VM until something connects to the QMP
>>> socket (e.g. qmp-shell). Once connected, no event is received on the QMP
>>> connection but the tracepoint is hit indicating that an event has been
>>> emitted. I suspect that the event is emitted while the QMP client is doing
>>> the initial negotiation.
>>>
>>> The reason I want to receive this event is that QEMU currently uses xenstore
>>> to communicate this information to the Xen toolstack (see
>>> xen-common.c:xen_change_state_handler) but we want to move to using QMP
>>> rather than xenstore for this kind of thing.
>>>
>>> Is this a known issue or just a bug that should be fixed?
>>
>> I'll leave it to Markus to say if it's a bug or not, but can't
>> you work around this by starting qemu with -S which leaves the guest
>> paused, and then continuing the guest when you have your QMP ?
>
> You can:
>
> <-- {"QMP": {"version": {"qemu": {"micro": 50, "minor": 10, "major": 2}, "package": " (v2.10.0-613-g10656079e1-dirty)"}, "capabilities": []}}
> --> { "execute": "qmp_capabilities" }
> <-- {"return": {}}
> --> { "execute": "cont" }
> <-- {"timestamp": {"seconds": 1510235984, "microseconds": 108550}, "event": "RESUME"}
> <-- {"return": {}}
>
> RESUME is sent in vm_prepare_start(), called from main() via vm_start(),
> but only if @autostart, i.e. no -S.
>
> The "wait" in the argument of -qmp makes QEMU wait for a QMP client to
> connect to the QMP socket, long before vm_start() gets called. However,
> having connected is not sufficient for receiving events, you also have
> to exit capabilities negotiation mode. Not possible until QEMU is
> running the main loop, which runs after the vm_start() quoted above.
>
> If QMP monitors became usable before entering main_loop(), we'd have a
> race condition instead. The only reliable way to get the RESUME event
> is -S.
>
> This adds one minor item to the long list of reasons why management
> software should pass -S.
>
> All clear now?
>
Yeah that makes sense thanks. I've now tested with -S and it works fine.
Cheers,
--
Ross Lagerwall
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2017-11-10 11:13 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2017-10-30 10:50 [Qemu-devel] QMP event missed during startup Ross Lagerwall
2017-10-30 17:18 ` Dr. David Alan Gilbert
2017-11-09 14:14 ` Markus Armbruster
2017-11-10 10:43 ` Ross Lagerwall
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.