From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:57783) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TdQRT-0004NI-15 for qemu-devel@nongnu.org; Tue, 27 Nov 2012 14:03:39 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1TdQRO-0003IE-Ui for qemu-devel@nongnu.org; Tue, 27 Nov 2012 14:03:34 -0500 Received: from mail-ia0-f173.google.com ([209.85.210.173]:56614) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TdQRO-0003I9-Ou for qemu-devel@nongnu.org; Tue, 27 Nov 2012 14:03:30 -0500 Received: by mail-ia0-f173.google.com with SMTP id w21so7622014iac.4 for ; Tue, 27 Nov 2012 11:03:30 -0800 (PST) From: Anthony Liguori In-Reply-To: <20121127124815.GD10280@amit.redhat.com> References: <1353850754-22704-1-git-send-email-alevy@redhat.com> <20121127124815.GD10280@amit.redhat.com> Date: Tue, 27 Nov 2012 13:03:22 -0600 Message-ID: <87lidm6f7p.fsf@codemonkey.ws> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: Re: [Qemu-devel] [PATCH] hw/virtio-serial-bus: replay guest open on destination List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Amit Shah , Alon Levy Cc: Gerd Hoffmann , Markus Armbruster , qemu-devel@nongnu.org Amit Shah writes: > On (Sun) 25 Nov 2012 [15:39:14], Alon Levy wrote: >> When migrating a host with with a spice agent running the mouse becomes >> non operational after the migration due to the agent state being >> inconsistent between the guest and the client if the client is using >> semi-seamless or switch host migration. >> >> After migration the target client has never received the guest_open >> initiated spice message. Virtio-serial holds this state information and >> migrates it, so replay that over the chardev post migration. Fix is not >> spice specific but spice is the only client that cares about it. > > Thanks for continuing to pursue this :) > >> rhbz #725965. >> --- >> hw/virtio-serial-bus.c | 6 ++++++ >> 1 file changed, 6 insertions(+) >> >> diff --git a/hw/virtio-serial-bus.c b/hw/virtio-serial-bus.c >> index efa8a81..ccce1fa 100644 >> --- a/hw/virtio-serial-bus.c >> +++ b/hw/virtio-serial-bus.c >> @@ -641,6 +641,7 @@ static void virtio_serial_post_load_timer_cb(void *opaque) >> VirtIOSerial *s = opaque; >> VirtIOSerialPort *port; >> uint8_t host_connected; >> + VirtIOSerialPortClass *vsc; >> >> for (i = 0 ; i < s->post_load.nr_active_ports; ++i) { >> port = s->post_load.connected[i].port; >> @@ -653,6 +654,11 @@ static void virtio_serial_post_load_timer_cb(void *opaque) >> send_control_event(port, VIRTIO_CONSOLE_PORT_OPEN, >> port->host_connected); >> } >> + vsc = VIRTIO_SERIAL_PORT_GET_CLASS(port); >> + if (port->guest_connected && vsc->guest_open) { >> + /* replay guest open */ >> + vsc->guest_open(port); >> + } > > I think the last time we discussed this, my objection was the guest > isn't really doing an open again, and since spice depends on the > guest's connectedness, spice should have a post-load hook or a similar > bh that would query virtio-serial for guest connectedness status, and, > if connected, do whatever setup is necessary. Agreed. Regards, Anthony Liguori > > Adding Gerd and Markus as I think they were involved in the discussion > last time as well. > > Amit