From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:35895) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UIwn5-0004qZ-GW for qemu-devel@nongnu.org; Fri, 22 Mar 2013 03:53:32 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UIwn4-0002di-4H for qemu-devel@nongnu.org; Fri, 22 Mar 2013 03:53:31 -0400 Received: from mx1.redhat.com ([209.132.183.28]:55353) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UIwn3-0002dd-QD for qemu-devel@nongnu.org; Fri, 22 Mar 2013 03:53:30 -0400 Message-ID: <514C0EC3.3090202@redhat.com> Date: Fri, 22 Mar 2013 08:56:51 +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> In-Reply-To: <87sj3o62gd.fsf@codemonkey.ws> 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: Anthony Liguori Cc: amit.shah@redhat.com, Alon Levy , qemu-devel@nongnu.org, kraxel@redhat.com Hi, On 03/21/2013 07:18 PM, Anthony Liguori wrote: > Alon Levy writes: > >> Note that the handler is called chr_is_guest_connected and not >> chr_is_fe_connected, consistent with other members of CharDriverState. > > Sorry, I don't get it. > > There isn't a notion of "connected" for the front-ends in the char > layer. And that is simply completely and utterly wrong. We've tried to explain this to you a number of times already. Yet you claim we've not explained it. Or we've not explained it properly. I must say however that I'm getting the feeling the problem is not us not explaining, but that you are not listening. Still let me try to explain it 1 more time, in 2 different ways: 1) At an abstract level a chardev fe + be is a pipe between somewhere and where-ever. Both ends of the pipe can be opened or closed, not just one. Frontends end inside the guest usually in the form of some piece of virtual hardware inside the guest. Just because the virtual hardware is there does not mean the guest has a driver, if the guest has a driver that creates a device-node for it, that does not mean there is a userspace process inside the guest which actually has the device-node open. So you see the front-end device-node inside the guest can be opened and closed. Most frontends cannot signal this to the backend but virtio-console can, and we want to know about it since we want to know if the user-space agent is there. 2) At the code level it clearly is there too, backend open-close is signalled to the frontend by means of the backend calling qemu_chr_be_event with an event of CHR_EVENT_OPENED and CHR_EVENT_CLOSED. Frontend open-close is signalled by the frontend calling qemu_chr_fe_open and qemu_chr_fe_close. Now the problem we have is that after migration the CHR_EVENT_OPENED gets replayed on the destination side but the qemu_chr_fe_open call does not. The logical place to replay the qemu_chr_fe_open would be in the frontend's migration handling code, as suggested here: http://lists.gnu.org/archive/html/qemu-devel/2012-11/msg02721.html But Amit did not like this approach, suggesting that instead we took care of this inside spice-qemu-char.c. Which is what we're trying to do now, but this requires spice-qemu-char.c being able to query the open state of the frontend, which is already being migrate by the virtio-console code in the form of the guest_connected variable, we just need to be able to get to that variable from the backend. Regards, Hans