Patchwork [2/2] spice-qemu-char: register interface on post load

login
register
mail settings
Submitter Alon Levy
Date March 21, 2013, 4:35 p.m.
Message ID <1363883716-30289-3-git-send-email-alevy@redhat.com>
Download mbox | patch
Permalink /patch/229763/
State New
Headers show

Comments

Alon Levy - March 21, 2013, 4:35 p.m.
The target has not seen the guest_connected event via
spice_chr_guest_open or spice_chr_write, and so spice server wrongly
assumes there is no agent active, while the client continues to send
motion events only by the agent channel, which the server ignores. The
net effect is that the mouse is static in the guest.

By registering the interface on post load spice server will pass on the
agent messages fixing the mouse behavior after migration.

Note that qemu_be_is_fe_connected is called when the vm is already
running, to avoid any possible order of vmstate loading issue, i.e.
device loading after chardev post_load being called back.

RHBZ #725965

Signed-off-by: Alon Levy <alevy@redhat.com>

v3: don't store any state in vmstate, get it via
qemu_be_is_fe_connected, that way we support multiple chardevices
without having to specify a device in vmstate_register.
---
 spice-qemu-char.c | 39 +++++++++++++++++++++++++++++++++++++++
 1 file changed, 39 insertions(+)
Hans de Goede - March 22, 2013, 8:07 a.m.
Ji,

On 03/21/2013 05:35 PM, Alon Levy wrote:
> The target has not seen the guest_connected event via
> spice_chr_guest_open or spice_chr_write, and so spice server wrongly
> assumes there is no agent active, while the client continues to send
> motion events only by the agent channel, which the server ignores. The
> net effect is that the mouse is static in the guest.
>
> By registering the interface on post load spice server will pass on the
> agent messages fixing the mouse behavior after migration.
>
> Note that qemu_be_is_fe_connected is called when the vm is already
> running, to avoid any possible order of vmstate loading issue, i.e.
> device loading after chardev post_load being called back.

This seems needlessly complicated, I agree you should wait with
calling qemu_be_is_fe_connected till the vm is running, but why not
simply use qemu_add_vm_change_state_handler for that, and in the
handler check for state == RUN_STATE_RUNNING ?

Regards,

Hans
Alon Levy - March 22, 2013, 8:16 a.m.
> Ji,

Ji,

> 
> On 03/21/2013 05:35 PM, Alon Levy wrote:
> > The target has not seen the guest_connected event via
> > spice_chr_guest_open or spice_chr_write, and so spice server
> > wrongly
> > assumes there is no agent active, while the client continues to
> > send
> > motion events only by the agent channel, which the server ignores.
> > The
> > net effect is that the mouse is static in the guest.
> >
> > By registering the interface on post load spice server will pass on
> > the
> > agent messages fixing the mouse behavior after migration.
> >
> > Note that qemu_be_is_fe_connected is called when the vm is already
> > running, to avoid any possible order of vmstate loading issue, i.e.
> > device loading after chardev post_load being called back.
> 
> This seems needlessly complicated, I agree you should wait with
> calling qemu_be_is_fe_connected till the vm is running, but why not
> simply use qemu_add_vm_change_state_handler for that, and in the
> handler check for state == RUN_STATE_RUNNING ?

If I do that I should register it on post load and unregister it after it's done, the code wouldn't be that much simpler but it does make the 1 ns timer go away, so I agree it looks better.

> 
> Regards,
> 
> Hans
>
Hans de Goede - March 22, 2013, 8:55 a.m.
Hi,

On 03/22/2013 09:16 AM, Alon Levy wrote:
>> Ji,
>
> Ji,
>
>>
>> On 03/21/2013 05:35 PM, Alon Levy wrote:
>>> The target has not seen the guest_connected event via
>>> spice_chr_guest_open or spice_chr_write, and so spice server
>>> wrongly
>>> assumes there is no agent active, while the client continues to
>>> send
>>> motion events only by the agent channel, which the server ignores.
>>> The
>>> net effect is that the mouse is static in the guest.
>>>
>>> By registering the interface on post load spice server will pass on
>>> the
>>> agent messages fixing the mouse behavior after migration.
>>>
>>> Note that qemu_be_is_fe_connected is called when the vm is already
>>> running, to avoid any possible order of vmstate loading issue, i.e.
>>> device loading after chardev post_load being called back.
>>
>> This seems needlessly complicated, I agree you should wait with
>> calling qemu_be_is_fe_connected till the vm is running, but why not
>> simply use qemu_add_vm_change_state_handler for that, and in the
>> handler check for state == RUN_STATE_RUNNING ?
>
> If I do that I should register it on post load and unregister it after it's done

Why, you can simply always have it there:

1) All it will do is, if transitioning to running and qemu_be_is_fe_connected returns
true, call vmc_register_interface, which is protected against being called multiple
times and if qemu_be_is_fe_connected returns true the vmc should always be registered.

2) The code will call qemu_be_is_fe_connected whenever the state changes to RUNNING,
this happens on vm-start and post-migrate, on vm-start qemu_be_is_fe_connected will
always return 0, so the whole thing is a nop.

Regards,

Hans

Patch

diff --git a/spice-qemu-char.c b/spice-qemu-char.c
index 8a9236d..c457cc3 100644
--- a/spice-qemu-char.c
+++ b/spice-qemu-char.c
@@ -2,6 +2,7 @@ 
 #include "trace.h"
 #include "ui/qemu-spice.h"
 #include "char/char.h"
+#include "migration/vmstate.h"
 #include <spice.h>
 #include <spice-experimental.h>
 #include <spice/protocol.h>
@@ -17,6 +18,9 @@  typedef struct SpiceCharDriver {
     uint8_t               *datapos;
     ssize_t               bufsize, datalen;
     QLIST_ENTRY(SpiceCharDriver) next;
+    struct {
+        QEMUTimer        *timer;
+    } post_load;
 } SpiceCharDriver;
 
 static QLIST_HEAD(, SpiceCharDriver) spice_chars =
@@ -173,6 +177,8 @@  static void spice_chr_close(struct CharDriverState *chr)
 #if SPICE_SERVER_VERSION >= 0x000c02
     g_free((char *)s->sin.portname);
 #endif
+    qemu_del_timer(s->post_load.timer);
+    qemu_free_timer(s->post_load.timer);
     g_free(s);
 }
 
@@ -205,6 +211,35 @@  static void print_allowed_subtypes(void)
     fprintf(stderr, "\n");
 }
 
+static void spice_chr_post_load_cb(void *opaque)
+{
+    SpiceCharDriver *s = opaque;
+
+    if (qemu_chr_be_is_fe_connected(s->chr)) {
+        spice_chr_guest_open(s->chr);
+    }
+}
+
+static int spice_chr_post_load(void *opaque, int version_id)
+{
+    SpiceCharDriver *s = opaque;
+
+    if (s && s->chr) {
+        qemu_mod_timer(s->post_load.timer, 1);
+    }
+    return 0;
+}
+
+static VMStateDescription spice_chr_vmstate = {
+    .name               = "spice-chr",
+    .version_id         = 1,
+    .minimum_version_id = 1,
+    .post_load          = spice_chr_post_load,
+    .fields = (VMStateField[]) {
+        VMSTATE_END_OF_LIST()
+    },
+};
+
 static CharDriverState *chr_open(const char *subtype)
 {
     CharDriverState *chr;
@@ -215,12 +250,16 @@  static CharDriverState *chr_open(const char *subtype)
     s->chr = chr;
     s->active = false;
     s->sin.subtype = g_strdup(subtype);
+    s->post_load.timer = qemu_new_timer_ns(vm_clock,
+                                           spice_chr_post_load_cb, s);
     chr->opaque = s;
     chr->chr_write = spice_chr_write;
     chr->chr_close = spice_chr_close;
     chr->chr_guest_open = spice_chr_guest_open;
     chr->chr_guest_close = spice_chr_guest_close;
 
+    vmstate_register(NULL, -1, &spice_chr_vmstate, s);
+
     QLIST_INSERT_HEAD(&spice_chars, s, next);
 
     return chr;