[Qemu-devel] [PATCH 0/4]: qmp: WAKEUP event related fixes

[Qemu-devel] [PATCH 0/4]: qmp: WAKEUP event related fixes

[Luiz Capitulino]

Fixes the RESET event being emitted on wakeup from S3. Changes when
the WAKEUP event is emitted and a few doc fixes.

 QMP/qmp-events.txt | 277 ++++++++++++++++++++++++++++-------------------------
 vl.c               |  18 +++-
 2 files changed, 164 insertions(+), 131 deletions(-)

[Qemu-devel] [PATCH 1/4] qmp: don't emit the RESET event on wakeup from S3

[Luiz Capitulino]

QEMU is basically using reset logic when waking up from S3. This
causes the QMP RESET event to be emitted, which is wrong. Also,
the runstate checks done in reset are not necessary for S3 wakeup.

Fix this by untangling wakeup from reset logic and passing
VMRESET_SILENT to qemu_system_reset() to avoid emitting the RESET
event.

Signed-off-by: Luiz Capitulino <lcapitulino@redhat.com>
---
 vl.c | 16 +++++++++++++++-
 1 file changed, 15 insertions(+), 1 deletion(-)

diff --git a/vl.c b/vl.c
index e71cb30..b642637 100644
--- a/vl.c
+++ b/vl.c
@@ -1293,6 +1293,7 @@ static pid_t shutdown_pid;
 static int powerdown_requested;
 static int debug_requested;
 static int suspend_requested;
+static int wakeup_requested;
 static NotifierList suspend_notifiers =
     NOTIFIER_LIST_INITIALIZER(suspend_notifiers);
 static NotifierList wakeup_notifiers =
@@ -1347,6 +1348,13 @@ static int qemu_suspend_requested(void)
     return r;
 }
 
+static int qemu_wakeup_requested(void)
+{
+    int r = wakeup_requested;
+    wakeup_requested = 0;
+    return r;
+}
+
 int qemu_powerdown_requested(void)
 {
     int r = powerdown_requested;
@@ -1454,7 +1462,7 @@ void qemu_system_wakeup_request(WakeupReason reason)
     runstate_set(RUN_STATE_RUNNING);
     monitor_protocol_event(QEVENT_WAKEUP, NULL);
     notifier_list_notify(&wakeup_notifiers, &reason);
-    reset_requested = 1;
+    wakeup_requested = 1;
     qemu_notify_event();
 }
 
@@ -1534,6 +1542,12 @@ static bool main_loop_should_exit(void)
             runstate_set(RUN_STATE_PAUSED);
         }
     }
+    if (qemu_wakeup_requested()) {
+        pause_all_vcpus();
+        cpu_synchronize_all_states();
+        qemu_system_reset(VMRESET_SILENT);
+        resume_all_vcpus();
+    }
     if (qemu_powerdown_requested()) {
         monitor_protocol_event(QEVENT_POWERDOWN, NULL);
         qemu_irq_raise(qemu_system_powerdown);
-- 
1.7.11.2.249.g31c7954.dirty

[Qemu-devel] [PATCH 2/4] qmp: emit the WAKEUP event when the guest is put to run

[Luiz Capitulino]

Today, the WAKEUP event is emitted when a wakeup _request_ is made.
This could be the system_wakeup command, for example.

A better semantic would be to emit the event when the guest is
already running, as that's what matters in the end. This commit does
that change.

In theory, this could break compatibility. In practice, it shouldn't
happen though, as clients shouldn't rely on timing characteristics of
the events. That is, a client relying that the guest is not running
when the event arrives may break if the event arrives after the guest
is already running.

This commit also adds the missing documentation for the WAKEUP event.

Signed-off-by: Luiz Capitulino <lcapitulino@redhat.com>
---
 QMP/qmp-events.txt | 13 +++++++++++++
 vl.c               |  2 +-
 2 files changed, 14 insertions(+), 1 deletion(-)

diff --git a/QMP/qmp-events.txt b/QMP/qmp-events.txt
index 9ba7079..b8afedb 100644
--- a/QMP/qmp-events.txt
+++ b/QMP/qmp-events.txt
@@ -264,6 +264,19 @@ Example:
 }}
 
 
+WAKEUP
+------
+
+Emitted when the guest has been waken up from S3 and is running.
+
+Data: None.
+
+Example:
+
+{ "event": "WATCHDOG",
+     "timestamp": { "seconds": 1344522075, "microseconds": 745528 } }
+
+
 WATCHDOG
 --------
 
diff --git a/vl.c b/vl.c
index b642637..9d783b7 100644
--- a/vl.c
+++ b/vl.c
@@ -1460,7 +1460,6 @@ void qemu_system_wakeup_request(WakeupReason reason)
         return;
     }
     runstate_set(RUN_STATE_RUNNING);
-    monitor_protocol_event(QEVENT_WAKEUP, NULL);
     notifier_list_notify(&wakeup_notifiers, &reason);
     wakeup_requested = 1;
     qemu_notify_event();
@@ -1547,6 +1546,7 @@ static bool main_loop_should_exit(void)
         cpu_synchronize_all_states();
         qemu_system_reset(VMRESET_SILENT);
         resume_all_vcpus();
+        monitor_protocol_event(QEVENT_WAKEUP, NULL);
     }
     if (qemu_powerdown_requested()) {
         monitor_protocol_event(QEVENT_POWERDOWN, NULL);
-- 
1.7.11.2.249.g31c7954.dirty

[Qemu-devel] [PATCH 3/4] qmp: qmp-events.txt: put events in alphabetical order

[Luiz Capitulino]

Signed-off-by: Luiz Capitulino <lcapitulino@redhat.com>
---
 QMP/qmp-events.txt | 266 ++++++++++++++++++++++++++---------------------------
 1 file changed, 130 insertions(+), 136 deletions(-)

diff --git a/QMP/qmp-events.txt b/QMP/qmp-events.txt
index b8afedb..e37a04e 100644
--- a/QMP/qmp-events.txt
+++ b/QMP/qmp-events.txt
@@ -1,6 +1,23 @@
                    QEMU Monitor Protocol Events
                    ============================
 
+BALLOON_CHANGE
+--------------
+
+Emitted when the guest changes the actual BALLOON level. This
+value is equivalent to the 'actual' field return by the
+'query-balloon' command
+
+Data:
+
+- "actual": actual level of the guest memory balloon in bytes (json-number)
+
+Example:
+
+{ "event": "BALLOON_CHANGE",
+    "data": { "actual": 944766976 },
+    "timestamp": { "seconds": 1267020223, "microseconds": 435656 } }
+
 BLOCK_IO_ERROR
 --------------
 
@@ -26,6 +43,57 @@ Example:
 Note: If action is "stop", a STOP event will eventually follow the
 BLOCK_IO_ERROR event.
 
+BLOCK_JOB_CANCELLED
+-------------------
+
+Emitted when a block job has been cancelled.
+
+Data:
+
+- "type":     Job type ("stream" for image streaming, json-string)
+- "device":   Device name (json-string)
+- "len":      Maximum progress value (json-int)
+- "offset":   Current progress value (json-int)
+              On success this is equal to len.
+              On failure this is less than len.
+- "speed":    Rate limit, bytes per second (json-int)
+
+Example:
+
+{ "event": "BLOCK_JOB_CANCELLED",
+     "data": { "type": "stream", "device": "virtio-disk0",
+               "len": 10737418240, "offset": 134217728,
+               "speed": 0 },
+     "timestamp": { "seconds": 1267061043, "microseconds": 959568 } }
+
+BLOCK_JOB_COMPLETED
+-------------------
+
+Emitted when a block job has completed.
+
+Data:
+
+- "type":     Job type ("stream" for image streaming, json-string)
+- "device":   Device name (json-string)
+- "len":      Maximum progress value (json-int)
+- "offset":   Current progress value (json-int)
+              On success this is equal to len.
+              On failure this is less than len.
+- "speed":    Rate limit, bytes per second (json-int)
+- "error":    Error message (json-string, optional)
+              Only present on failure.  This field contains a human-readable
+              error message.  There are no semantics other than that streaming
+              has failed and clients should not try to interpret the error
+              string.
+
+Example:
+
+{ "event": "BLOCK_JOB_COMPLETED",
+     "data": { "type": "stream", "device": "virtio-disk0",
+               "len": 10737418240, "offset": 10737418240,
+               "speed": 0 },
+     "timestamp": { "seconds": 1267061043, "microseconds": 959568 } }
+
 DEVICE_TRAY_MOVED
 -----------------
 
@@ -98,6 +166,68 @@ Example:
 Note: If the command-line option "-no-shutdown" has been specified, a STOP
 event will eventually follow the SHUTDOWN event.
 
+SPICE_CONNECTED, SPICE_DISCONNECTED
+-----------------------------------
+
+Emitted when a SPICE client connects or disconnects.
+
+Data:
+
+- "server": Server information (json-object)
+  - "host": IP address (json-string)
+  - "port": port number (json-string)
+  - "family": address family (json-string, "ipv4" or "ipv6")
+- "client": Client information (json-object)
+  - "host": IP address (json-string)
+  - "port": port number (json-string)
+  - "family": address family (json-string, "ipv4" or "ipv6")
+
+Example:
+
+{ "timestamp": {"seconds": 1290688046, "microseconds": 388707},
+  "event": "SPICE_CONNECTED",
+  "data": {
+    "server": { "port": "5920", "family": "ipv4", "host": "127.0.0.1"},
+    "client": {"port": "52873", "family": "ipv4", "host": "127.0.0.1"}
+}}
+
+SPICE_INITIALIZED
+-----------------
+
+Emitted after initial handshake and authentication takes place (if any)
+and the SPICE channel is up'n'running
+
+Data:
+
+- "server": Server information (json-object)
+  - "host": IP address (json-string)
+  - "port": port number (json-string)
+  - "family": address family (json-string, "ipv4" or "ipv6")
+  - "auth": authentication method (json-string, optional)
+- "client": Client information (json-object)
+  - "host": IP address (json-string)
+  - "port": port number (json-string)
+  - "family": address family (json-string, "ipv4" or "ipv6")
+  - "connection-id": spice connection id.  All channels with the same id
+                     belong to the same spice session (json-int)
+  - "channel-type": channel type.  "1" is the main control channel, filter for
+                    this one if you want track spice sessions only (json-int)
+  - "channel-id": channel id.  Usually "0", might be different needed when
+                  multiple channels of the same type exist, such as multiple
+                  display channels in a multihead setup (json-int)
+  - "tls": whevener the channel is encrypted (json-bool)
+
+Example:
+
+{ "timestamp": {"seconds": 1290688046, "microseconds": 417172},
+  "event": "SPICE_INITIALIZED",
+  "data": {"server": {"auth": "spice", "port": "5921",
+                      "family": "ipv4", "host": "127.0.0.1"},
+           "client": {"port": "49004", "family": "ipv4", "channel-type": 3,
+                      "connection-id": 1804289383, "host": "127.0.0.1",
+                      "channel-id": 0, "tls": true}
+}}
+
 STOP
 ----
 
@@ -200,70 +330,6 @@ Example:
                     "host": "127.0.0.1", "sasl_username": "luiz" } },
         "timestamp": { "seconds": 1263475302, "microseconds": 150772 } }
 
-SPICE_CONNECTED, SPICE_DISCONNECTED
------------------------------------
-
-Emitted when a SPICE client connects or disconnects.
-
-Data:
-
-- "server": Server information (json-object)
-  - "host": IP address (json-string)
-  - "port": port number (json-string)
-  - "family": address family (json-string, "ipv4" or "ipv6")
-- "client": Client information (json-object)
-  - "host": IP address (json-string)
-  - "port": port number (json-string)
-  - "family": address family (json-string, "ipv4" or "ipv6")
-
-Example:
-
-{ "timestamp": {"seconds": 1290688046, "microseconds": 388707},
-  "event": "SPICE_CONNECTED",
-  "data": {
-    "server": { "port": "5920", "family": "ipv4", "host": "127.0.0.1"},
-    "client": {"port": "52873", "family": "ipv4", "host": "127.0.0.1"}
-}}
-
-
-SPICE_INITIALIZED
------------------
-
-Emitted after initial handshake and authentication takes place (if any)
-and the SPICE channel is up'n'running
-
-Data:
-
-- "server": Server information (json-object)
-  - "host": IP address (json-string)
-  - "port": port number (json-string)
-  - "family": address family (json-string, "ipv4" or "ipv6")
-  - "auth": authentication method (json-string, optional)
-- "client": Client information (json-object)
-  - "host": IP address (json-string)
-  - "port": port number (json-string)
-  - "family": address family (json-string, "ipv4" or "ipv6")
-  - "connection-id": spice connection id.  All channels with the same id
-                     belong to the same spice session (json-int)
-  - "channel-type": channel type.  "1" is the main control channel, filter for
-                    this one if you want track spice sessions only (json-int)
-  - "channel-id": channel id.  Usually "0", might be different needed when
-                  multiple channels of the same type exist, such as multiple
-                  display channels in a multihead setup (json-int)
-  - "tls": whevener the channel is encrypted (json-bool)
-
-Example:
-
-{ "timestamp": {"seconds": 1290688046, "microseconds": 417172},
-  "event": "SPICE_INITIALIZED",
-  "data": {"server": {"auth": "spice", "port": "5921",
-                      "family": "ipv4", "host": "127.0.0.1"},
-           "client": {"port": "49004", "family": "ipv4", "channel-type": 3,
-                      "connection-id": 1804289383, "host": "127.0.0.1",
-                      "channel-id": 0, "tls": true}
-}}
-
-
 WAKEUP
 ------
 
@@ -276,7 +342,6 @@ Example:
 { "event": "WATCHDOG",
      "timestamp": { "seconds": 1344522075, "microseconds": 745528 } }
 
-
 WATCHDOG
 --------
 
@@ -295,74 +360,3 @@ Example:
 
 Note: If action is "reset", "shutdown", or "pause" the WATCHDOG event is
 followed respectively by the RESET, SHUTDOWN, or STOP events.
-
-
-BLOCK_JOB_COMPLETED
--------------------
-
-Emitted when a block job has completed.
-
-Data:
-
-- "type":     Job type ("stream" for image streaming, json-string)
-- "device":   Device name (json-string)
-- "len":      Maximum progress value (json-int)
-- "offset":   Current progress value (json-int)
-              On success this is equal to len.
-              On failure this is less than len.
-- "speed":    Rate limit, bytes per second (json-int)
-- "error":    Error message (json-string, optional)
-              Only present on failure.  This field contains a human-readable
-              error message.  There are no semantics other than that streaming
-              has failed and clients should not try to interpret the error
-              string.
-
-Example:
-
-{ "event": "BLOCK_JOB_COMPLETED",
-     "data": { "type": "stream", "device": "virtio-disk0",
-               "len": 10737418240, "offset": 10737418240,
-               "speed": 0 },
-     "timestamp": { "seconds": 1267061043, "microseconds": 959568 } }
-
-
-BLOCK_JOB_CANCELLED
--------------------
-
-Emitted when a block job has been cancelled.
-
-Data:
-
-- "type":     Job type ("stream" for image streaming, json-string)
-- "device":   Device name (json-string)
-- "len":      Maximum progress value (json-int)
-- "offset":   Current progress value (json-int)
-              On success this is equal to len.
-              On failure this is less than len.
-- "speed":    Rate limit, bytes per second (json-int)
-
-Example:
-
-{ "event": "BLOCK_JOB_CANCELLED",
-     "data": { "type": "stream", "device": "virtio-disk0",
-               "len": 10737418240, "offset": 134217728,
-               "speed": 0 },
-     "timestamp": { "seconds": 1267061043, "microseconds": 959568 } }
-
-
-BALLOON_CHANGE
-----------
-
-Emitted when the guest changes the actual BALLOON level. This
-value is equivalent to the 'actual' field return by the
-'query-balloon' command
-
-Data:
-
-- "actual": actual level of the guest memory balloon in bytes (json-number)
-
-Example:
-
-{ "event": "BALLOON_CHANGE",
-    "data": { "actual": 944766976 },
-    "timestamp": { "seconds": 1267020223, "microseconds": 435656 } }
-- 
1.7.11.2.249.g31c7954.dirty

[Qemu-devel] [PATCH 4/4] qmp: qmp-events.txt: add missing doc for the SUSPEND event

[Luiz Capitulino]

Signed-off-by: Luiz Capitulino <lcapitulino@redhat.com>
---
 QMP/qmp-events.txt | 12 ++++++++++++
 1 file changed, 12 insertions(+)

diff --git a/QMP/qmp-events.txt b/QMP/qmp-events.txt
index e37a04e..2001a71 100644
--- a/QMP/qmp-events.txt
+++ b/QMP/qmp-events.txt
@@ -240,6 +240,18 @@ Example:
 { "event": "STOP",
     "timestamp": { "seconds": 1267041730, "microseconds": 281295 } }
 
+SUSPEND
+-------
+
+Emitted when guest enters S3 state.
+
+Data: None.
+
+Example:
+
+{ "event": "SUSPEND",
+     "timestamp": { "seconds": 1344456160, "microseconds": 309119 } }
+
 VNC_CONNECTED
 -------------
 
-- 
1.7.11.2.249.g31c7954.dirty

Re: [Qemu-devel] [PATCH 2/4] qmp: emit the WAKEUP event when the guest is put to run

[Eric Blake]

[-- Attachment #1: Type: text/plain, Size: 1018 bytes --]

On 08/09/2012 11:28 AM, Luiz Capitulino wrote:
> Today, the WAKEUP event is emitted when a wakeup _request_ is made.
> This could be the system_wakeup command, for example.
> 
> A better semantic would be to emit the event when the guest is
> already running, as that's what matters in the end. This commit does
> that change.
> 
> In theory, this could break compatibility. In practice, it shouldn't
> happen though, as clients shouldn't rely on timing characteristics of
> the events. That is, a client relying that the guest is not running
> when the event arrives may break if the event arrives after the guest
> is already running.

Yeah, no problem with that semantic change from libvirt.


> +WAKEUP
> +------
> +
> +Emitted when the guest has been waken up from S3 and is running.

grammar:

s/has been waken/has woken/

or maybe

s/has been waken up/has been awakened/

-- 
Eric Blake   eblake@redhat.com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 620 bytes --]

Re: [Qemu-devel] [PATCH 3/4] qmp: qmp-events.txt: put events in alphabetical order

[Eric Blake]

[-- Attachment #1: Type: text/plain, Size: 2408 bytes --]

On 08/09/2012 11:28 AM, Luiz Capitulino wrote:
> Signed-off-by: Luiz Capitulino <lcapitulino@redhat.com>
> ---
>  QMP/qmp-events.txt | 266 ++++++++++++++++++++++++++---------------------------
>  1 file changed, 130 insertions(+), 136 deletions(-)

Code motion that deletes 6 more lines than it adds?  I'm assuming those
were blank lines, and that spacing is more consistent now, but it's
nicer to see a code motion patch with matching diffstat.

Reviewed-by: Eric Blake <eblake@redhat.com>

> 
> diff --git a/QMP/qmp-events.txt b/QMP/qmp-events.txt
> index b8afedb..e37a04e 100644
> --- a/QMP/qmp-events.txt
> +++ b/QMP/qmp-events.txt

Nits to possibly address in a followup patch (do NOT fix them at the
same time as code motion, though):

>  
> +SPICE_CONNECTED, SPICE_DISCONNECTED
> +-----------------------------------
> +
> +Emitted when a SPICE client connects or disconnects.

Should this be broken into two listings?

> +SPICE_INITIALIZED
> +-----------------
> +
> +Emitted after initial handshake and authentication takes place (if any)
> +and the SPICE channel is up'n'running

Do we like this cutesy abbreviation, or should we spell out 'and'?

> +
> +Data:
> +
> +- "server": Server information (json-object)
> +  - "host": IP address (json-string)
> +  - "port": port number (json-string)
> +  - "family": address family (json-string, "ipv4" or "ipv6")
> +  - "auth": authentication method (json-string, optional)
> +- "client": Client information (json-object)
> +  - "host": IP address (json-string)
> +  - "port": port number (json-string)
> +  - "family": address family (json-string, "ipv4" or "ipv6")
> +  - "connection-id": spice connection id.  All channels with the same id
> +                     belong to the same spice session (json-int)
> +  - "channel-type": channel type.  "1" is the main control channel, filter for
> +                    this one if you want track spice sessions only (json-int)
> +  - "channel-id": channel id.  Usually "0", might be different needed when
> +                  multiple channels of the same type exist, such as multiple
> +                  display channels in a multihead setup (json-int)
> +  - "tls": whevener the channel is encrypted (json-bool)

s/whevener/whether/

-- 
Eric Blake   eblake@redhat.com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 620 bytes --]

Re: [Qemu-devel] [PATCH 4/4] qmp: qmp-events.txt: add missing doc for the SUSPEND event

[Eric Blake]

[-- Attachment #1: Type: text/plain, Size: 898 bytes --]

On 08/09/2012 11:28 AM, Luiz Capitulino wrote:
> Signed-off-by: Luiz Capitulino <lcapitulino@redhat.com>
> ---
>  QMP/qmp-events.txt | 12 ++++++++++++
>  1 file changed, 12 insertions(+)

Reviewed-by: Eric Blake <eblake@redhat.com>

> 
> diff --git a/QMP/qmp-events.txt b/QMP/qmp-events.txt
> index e37a04e..2001a71 100644
> --- a/QMP/qmp-events.txt
> +++ b/QMP/qmp-events.txt
> @@ -240,6 +240,18 @@ Example:
>  { "event": "STOP",
>      "timestamp": { "seconds": 1267041730, "microseconds": 281295 } }
>  
> +SUSPEND
> +-------
> +
> +Emitted when guest enters S3 state.
> +
> +Data: None.
> +
> +Example:
> +
> +{ "event": "SUSPEND",
> +     "timestamp": { "seconds": 1344456160, "microseconds": 309119 } }
> +
>  VNC_CONNECTED
>  -------------
>  
> 

-- 
Eric Blake   eblake@redhat.com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 620 bytes --]

Re: [Qemu-devel] [PATCH 3/4] qmp: qmp-events.txt: put events in alphabetical order

[Luiz Capitulino]

On Thu, 09 Aug 2012 13:29:32 -0600
Eric Blake <eblake@redhat.com> wrote:

> On 08/09/2012 11:28 AM, Luiz Capitulino wrote:
> > Signed-off-by: Luiz Capitulino <lcapitulino@redhat.com>
> > ---
> >  QMP/qmp-events.txt | 266 ++++++++++++++++++++++++++---------------------------
> >  1 file changed, 130 insertions(+), 136 deletions(-)
> 
> Code motion that deletes 6 more lines than it adds?  I'm assuming those
> were blank lines, and that spacing is more consistent now, but it's
> nicer to see a code motion patch with matching diffstat.

Yes, blank lines. I'll avoid doing this in the future.

> 
> Reviewed-by: Eric Blake <eblake@redhat.com>
> 
> > 
> > diff --git a/QMP/qmp-events.txt b/QMP/qmp-events.txt
> > index b8afedb..e37a04e 100644
> > --- a/QMP/qmp-events.txt
> > +++ b/QMP/qmp-events.txt
> 
> Nits to possibly address in a followup patch (do NOT fix them at the
> same time as code motion, though):
> 
> >  
> > +SPICE_CONNECTED, SPICE_DISCONNECTED
> > +-----------------------------------
> > +
> > +Emitted when a SPICE client connects or disconnects.
> 
> Should this be broken into two listings?
> 
> > +SPICE_INITIALIZED
> > +-----------------
> > +
> > +Emitted after initial handshake and authentication takes place (if any)
> > +and the SPICE channel is up'n'running
> 
> Do we like this cutesy abbreviation, or should we spell out 'and'?
> 
> > +
> > +Data:
> > +
> > +- "server": Server information (json-object)
> > +  - "host": IP address (json-string)
> > +  - "port": port number (json-string)
> > +  - "family": address family (json-string, "ipv4" or "ipv6")
> > +  - "auth": authentication method (json-string, optional)
> > +- "client": Client information (json-object)
> > +  - "host": IP address (json-string)
> > +  - "port": port number (json-string)
> > +  - "family": address family (json-string, "ipv4" or "ipv6")
> > +  - "connection-id": spice connection id.  All channels with the same id
> > +                     belong to the same spice session (json-int)
> > +  - "channel-type": channel type.  "1" is the main control channel, filter for
> > +                    this one if you want track spice sessions only (json-int)
> > +  - "channel-id": channel id.  Usually "0", might be different needed when
> > +                  multiple channels of the same type exist, such as multiple
> > +                  display channels in a multihead setup (json-int)
> > +  - "tls": whevener the channel is encrypted (json-bool)
> 
> s/whevener/whether/
> 

Re: [Qemu-devel] [PATCH 2/4] qmp: emit the WAKEUP event when the guest is put to run

[Luiz Capitulino]

On Thu, 09 Aug 2012 11:57:38 -0600
Eric Blake <eblake@redhat.com> wrote:

> On 08/09/2012 11:28 AM, Luiz Capitulino wrote:
> > Today, the WAKEUP event is emitted when a wakeup _request_ is made.
> > This could be the system_wakeup command, for example.
> > 
> > A better semantic would be to emit the event when the guest is
> > already running, as that's what matters in the end. This commit does
> > that change.
> > 
> > In theory, this could break compatibility. In practice, it shouldn't
> > happen though, as clients shouldn't rely on timing characteristics of
> > the events. That is, a client relying that the guest is not running
> > when the event arrives may break if the event arrives after the guest
> > is already running.
> 
> Yeah, no problem with that semantic change from libvirt.
> 
> 
> > +WAKEUP
> > +------
> > +
> > +Emitted when the guest has been waken up from S3 and is running.
> 
> grammar:
> 
> s/has been waken/has woken/

Fixed in v2. If I don't respin I'll merge the fixed version in the
qmp branch (I won't respin just because of this).

> 
> or maybe
> 
> s/has been waken up/has been awakened/
> 

Re: [Qemu-devel] [PATCH 0/4]: qmp: WAKEUP event related fixes

[Gerd Hoffmann]

On 08/09/12 19:28, Luiz Capitulino wrote:
> Fixes the RESET event being emitted on wakeup from S3. Changes when
> the WAKEUP event is emitted and a few doc fixes.

series looks good to me.

Acked-by: Gerd Hoffmann <kraxel@redhat.com>

cheers,
  Gerd