From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:52414) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1S8Swy-00058m-LI for qemu-devel@nongnu.org; Fri, 16 Mar 2012 04:56:15 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1S8Swr-0002MV-EP for qemu-devel@nongnu.org; Fri, 16 Mar 2012 04:55:52 -0400 Received: from mail-pz0-f45.google.com ([209.85.210.45]:40786) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1S8Swr-0002MA-5A for qemu-devel@nongnu.org; Fri, 16 Mar 2012 04:55:45 -0400 Received: by dadp14 with SMTP id p14so5913256dad.4 for ; Fri, 16 Mar 2012 01:55:42 -0700 (PDT) Sender: Paolo Bonzini Message-ID: <4F630004.7030406@redhat.com> Date: Fri, 16 Mar 2012 09:55:32 +0100 From: Paolo Bonzini MIME-Version: 1.0 References: <4E859A76.2000808@siemens.com> <201203151912.47455.marek.vasut@gmail.com> <4F6264EF.90709@web.de> <201203160152.55783.marek.vasut@gmail.com> <4F62F70D.3050103@web.de> In-Reply-To: <4F62F70D.3050103@web.de> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH 2/2] Drop obsolete nographic timer List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Jan Kiszka Cc: Blue Swirl , Marek Vasut , Anthony Liguori , qemu-devel@nongnu.org Il 16/03/2012 09:17, Jan Kiszka ha scritto: > I'm starting to understand the issue: The serial port can only accept a > single byte. Once this arrived, serial_can_receive1 returns 0, and the > backend fd is not longer polled by the io-thread. This should change > again as soon as the guest read that byte. But qemu_chr_accept_input, > which is properly called by the serial device, didn't kick the io-thread > in some way. I solved it this way now: > > diff --git a/qemu-char.c b/qemu-char.c > index 9a5be75..a589a84 100644 > --- a/qemu-char.c > +++ b/qemu-char.c > @@ -177,6 +177,7 @@ void qemu_chr_accept_input(CharDriverState *s) > { > if (s->chr_accept_input) > s->chr_accept_input(s); > + qemu_notify_event(); > } > > void qemu_chr_fe_printf(CharDriverState *s, const char *fmt, ...) > > > But I'm not yet sure if this is correct. Comments welcome! I think so. qemu_chr_accept_input signals that qemu_chr_be_can_write could have changed, which means that the can_read handler could have changed and has to be reevaluated. qemu_notify_event is the right way to do so. Paolo