From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from eggs.gnu.org ([140.186.70.92]:57209)
	by lists.gnu.org with esmtp (Exim 4.71)
	(envelope-from <amit.shah@redhat.com>) id 1RgGau-0002XZ-0S
	for qemu-devel@nongnu.org; Thu, 29 Dec 2011 09:04:33 -0500
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
	(envelope-from <amit.shah@redhat.com>) id 1RgGao-0007wn-Pj
	for qemu-devel@nongnu.org; Thu, 29 Dec 2011 09:04:31 -0500
Received: from mx1.redhat.com ([209.132.183.28]:46148)
	by eggs.gnu.org with esmtp (Exim 4.71)
	(envelope-from <amit.shah@redhat.com>) id 1RgGao-0007wZ-4b
	for qemu-devel@nongnu.org; Thu, 29 Dec 2011 09:04:26 -0500
Date: Thu, 29 Dec 2011 19:34:07 +0530
From: Amit Shah <amit.shah@redhat.com>
Message-ID: <20111229140407.GC4576@amit.redhat.com>
References: <4EE9EBB9.9020300@de.ibm.com>
 <4EFC616F.4060806@de.ibm.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <4EFC616F.4060806@de.ibm.com>
Subject: Re: [Qemu-devel] [PATCHv2] Fix virtio-console failure on
	unconnected pty
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: Christian Borntraeger <borntraeger@de.ibm.com>
Cc: "qemu-devel@nongnu.org" <qemu-devel@nongnu.org>, Alexander Graf <agraf@suse.de>

On (Thu) 29 Dec 2011 [13:47:43], Christian Borntraeger wrote:
> From: Christian Borntraeger <borntraeger@de.ibm.com>
>     
> when I tried qemu with -virtio-console pty the guest hangs and attaching on /dev/pts/<x> does
> not return anything if the attachement is too late.
> Turns out that the console is already throttled and the guest is heavily spinning but get_buf
> never returns the buffer. There seems to be no way for the console to unthrottle the port.
>     
> For the virtio-serial use case we dont want to loose data but for the console case we better
> drop  data instead of "killing" the guest console. If we get chardev->frontend notification
> and a better behaving virtio-console we can revert this fix.
>     
> Signed-off-by: Christian Borntraeger <borntraeger@de.ibm.com>
> 
> ---
>  hw/virtio-serial-bus.c |   14 +++++++++++++-
>  1 file changed, 13 insertions(+), 1 deletion(-)
> 
> Index: b/hw/virtio-serial-bus.c
> ===================================================================
> --- a/hw/virtio-serial-bus.c
> +++ b/hw/virtio-serial-bus.c
> @@ -163,7 +163,19 @@ static void do_flush_queued_data(VirtIOS
>                  abort();
>              }
>              if (ret == -EAGAIN || (ret >= 0 && ret < buf_size)) {
> -                virtio_serial_throttle_port(port, true);

I'm surprised: did you test this with upstream qemu?  That codebase
doesn't yet throttle writes, and this code path won't execute.  Does
it really not reproduce with this patch?

> +		/*
> +                 * this is a temporary check until chardevs can signal to
> +                 * frontends that they are writable again. This prevents
> +                 * the console from going into throttled mode (forever)
> +                 * if virtio-console is connected to a pty without a
> +                 * listener. Otherwise the guest spins forever.
> +                 * We can revert this if
> +                 * 1: chardevs can notify frondends
> +                 * 2: the guest driver does not spin in these cases
> +                 */
> +                if (!info->is_console) {
> +                    virtio_serial_throttle_port(port, true);
> +                }
>                  port->iov_idx = i;
>                  if (ret > 0) {
>                      port->iov_offset += ret;
> 

		Amit