From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:50219) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UIxka-00035x-4S for qemu-devel@nongnu.org; Fri, 22 Mar 2013 04:55:01 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UIxkY-0006iL-N5 for qemu-devel@nongnu.org; Fri, 22 Mar 2013 04:55:00 -0400 Received: from mx1.redhat.com ([209.132.183.28]:35368) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UIxkY-0006iB-DX for qemu-devel@nongnu.org; Fri, 22 Mar 2013 04:54:58 -0400 Message-ID: <514C1D2C.9000509@redhat.com> Date: Fri, 22 Mar 2013 09:58:20 +0100 From: Hans de Goede MIME-Version: 1.0 References: <87boadc2yp.fsf@codemonkey.ws> <1363883716-30289-1-git-send-email-alevy@redhat.com> <1363883716-30289-2-git-send-email-alevy@redhat.com> <87sj3o62gd.fsf@codemonkey.ws> <514C158C.7050001@redhat.com> In-Reply-To: <514C158C.7050001@redhat.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH 1/2] char: add qemu_chr_be_is_fe_connected List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Gerd Hoffmann Cc: amit.shah@redhat.com, Anthony Liguori , Alon Levy , qemu-devel@nongnu.org Hi, On 03/22/2013 09:25 AM, Gerd Hoffmann wrote: > Hi, > >> There isn't a notion of "connected" for the front-ends in the char >> layer. The closest thing is whether add_handlers() have been called or >> not. > > It isn't new. There are qemu_chr_fe_open + qemu_chr_fe_close doing > exactly that signaling (whenever someone has opened the virtio-serial > port, i.e. whenever the guest agent is active or not). > > Problem is the chardev forgets this state over migration. > > So we need a way to restore the state. virtio-serial knows it of course > as this is guest state it has to keep track of it. We just need a way > the chardev can figure what the current state is after migration. > > The options I see: > > (1) Have chardev store the state itself in a new migration section. > This is what I've NAK'ed. First, because live-migration host > state is a can of worms I don't want open. Second because it > actually isn't host state. > > (2) virtio-serial could just call qemu_chr_fe_open in > post_migration hook. Could have unwanted side effects as > the chardev can't figure whenever this is a post-load call > or a guest-open call. > > (3) Add a new qemu_chr_fe_* call for virtio-serial to notify the > chardev. This was the next proposal from Alon > > (4) Do it the other way around: Allow the chardev query what the > current state is. This patch series. > Thanks for the above overview, very useful! > (5) Cut off the chardev layer altogether and implement spicevmc as > virtio-serial port. Your proposal if I understand it correctly. > Makes sense, but breaks backward compatibility, so even when > doing this we must fix the chardev spicevmc bug somehow. I've to nack this one, spicevmc is a chardev backend which is also used with other frontends then just virtio-console, atm it is also used together with the usb-redir and smartcard frontends and there is no reason why it could not be used with others in the future, so: NACK. Regards, Hans