From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from eggs.gnu.org ([208.118.235.92]:37454)
	by lists.gnu.org with esmtp (Exim 4.71)
	(envelope-from <kraxel@redhat.com>) id 1UJ4Hg-00017h-3N
	for qemu-devel@nongnu.org; Fri, 22 Mar 2013 11:53:43 -0400
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
	(envelope-from <kraxel@redhat.com>) id 1UJ4Hd-00007m-Kk
	for qemu-devel@nongnu.org; Fri, 22 Mar 2013 11:53:35 -0400
Received: from mx1.redhat.com ([209.132.183.28]:59311)
	by eggs.gnu.org with esmtp (Exim 4.71)
	(envelope-from <kraxel@redhat.com>) id 1UJ4Hd-00007W-BQ
	for qemu-devel@nongnu.org; Fri, 22 Mar 2013 11:53:33 -0400
Message-ID: <514C7E79.9000803@redhat.com>
Date: Fri, 22 Mar 2013 16:53:29 +0100
From: Gerd Hoffmann <kraxel@redhat.com>
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> <514C0EC3.3090202@redhat.com>
	<87wqszv8zr.fsf@codemonkey.ws>
In-Reply-To: <87wqszv8zr.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: <qemu-devel.nongnu.org>
List-Unsubscribe: <https://lists.nongnu.org/mailman/options/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.nongnu.org/archive/html/qemu-devel>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <https://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: Anthony Liguori <aliguori@us.ibm.com>
Cc: amit.shah@redhat.com, Hans de Goede <hdegoede@redhat.com>, Alon Levy <alevy@redhat.com>, qemu-devel@nongnu.org

  Hi,

> Okay, let's use your example here with a standard UART.  In the
> following sequence, I should receive:
> 
> 1) Starts guest
> 2) When guest initializes the UART, qemu_chr_fe_open()
> 3) Reboot guest
> 4) Receive qemu_chr_fe_close()
> 5) Boot new guest without a UART driver
> 6) Nothing is received

Well, with virtio-serial the logic is slightly different.
qemu_chr_fe_open() is called when a process opens
/dev/virtio-ports/$name, not when the virtio-serial driver loads.

I'm not sure whenever the qemu uart emulation can reliable do the same.
 Guest loading the uart driver can probably detected without too much
trouble.  But detecting a process opening /dev/ttySx might not be
possible.  Depends on the guest driver implementation.  For
virtio-serial it is trivial, there is a control message for that ;)

> And for me, the most logical thing is to call qemu_chr_fe_open() in
> post_load for the device.

Ok, just lets do that then.

cheers,
  Gerd