From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:49659) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UIxi8-0001rN-Iq for qemu-devel@nongnu.org; Fri, 22 Mar 2013 04:52:30 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UIxi7-0006Hi-BQ for qemu-devel@nongnu.org; Fri, 22 Mar 2013 04:52:28 -0400 Received: from mx1.redhat.com ([209.132.183.28]:4654) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UIxi7-0006He-3S for qemu-devel@nongnu.org; Fri, 22 Mar 2013 04:52:27 -0400 Message-ID: <514C1C93.5060207@redhat.com> Date: Fri, 22 Mar 2013 09:55:47 +0100 From: Hans de Goede MIME-Version: 1.0 References: <1746253387.13066488.1363940210526.JavaMail.root@redhat.com> In-Reply-To: <1746253387.13066488.1363940210526.JavaMail.root@redhat.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH 2/2] spice-qemu-char: register interface on post load List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Alon Levy Cc: amit shah , aliguori@us.ibm.com, qemu-devel@nongnu.org, kraxel@redhat.com 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