| Message ID | 1363883716-30289-3-git-send-email-alevy@redhat.com |
|---|---|
| State | New |
| Headers | show |
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
> 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 >
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
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;
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(+)