From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:41000) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UIx9h-0003Av-GW for qemu-devel@nongnu.org; Fri, 22 Mar 2013 04:16:54 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UIx9g-0002M4-DH for qemu-devel@nongnu.org; Fri, 22 Mar 2013 04:16:53 -0400 Received: from mx4-phx2.redhat.com ([209.132.183.25]:58573) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UIx9g-0002Lv-5F for qemu-devel@nongnu.org; Fri, 22 Mar 2013 04:16:52 -0400 Date: Fri, 22 Mar 2013 04:16:50 -0400 (EDT) From: Alon Levy Message-ID: <1746253387.13066488.1363940210526.JavaMail.root@redhat.com> In-Reply-To: <514C112F.6000301@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 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: Hans de Goede Cc: amit shah , aliguori@us.ibm.com, qemu-devel@nongnu.org, kraxel@redhat.com > 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 >