From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:43196) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UIxIQ-0006w6-LS for qemu-devel@nongnu.org; Fri, 22 Mar 2013 04:25:55 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UIxIP-0005P4-3J for qemu-devel@nongnu.org; Fri, 22 Mar 2013 04:25:54 -0400 Received: from mx1.redhat.com ([209.132.183.28]:47291) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UIxIO-0005On-SU for qemu-devel@nongnu.org; Fri, 22 Mar 2013 04:25:53 -0400 Message-ID: <514C158C.7050001@redhat.com> Date: Fri, 22 Mar 2013 09:25:48 +0100 From: Gerd Hoffmann 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> In-Reply-To: <87sj3o62gd.fsf@codemonkey.ws> Content-Type: text/plain; charset=ISO-8859-1 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: Anthony Liguori Cc: amit.shah@redhat.com, hdegoede@redhat.com, Alon Levy , qemu-devel@nongnu.org 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. (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. Hope this clarifies, Gerd