From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=36226 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1P8E5S-0002pJ-FK for qemu-devel@nongnu.org; Tue, 19 Oct 2010 11:26:58 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1P8E5K-0005A6-3y for qemu-devel@nongnu.org; Tue, 19 Oct 2010 11:26:50 -0400 Received: from goliath.siemens.de ([192.35.17.28]:23479) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1P8E5J-00059W-RM for qemu-devel@nongnu.org; Tue, 19 Oct 2010 11:26:42 -0400 Message-ID: <4CBDB8AE.5050904@siemens.com> Date: Tue, 19 Oct 2010 17:26:38 +0200 From: Jan Kiszka MIME-Version: 1.0 References: <4CBDB361.1060606@siemens.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [Qemu-devel] Re: [PATCH][RESEND] char: Flush read buffer in mux_chr_can_read List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Alexander Graf Cc: Anthony Liguori , qemu-devel Am 19.10.2010 17:22, Alexander Graf wrote: > > Am 19.10.2010 um 17:04 schrieb Jan Kiszka : > >> Move the buffer flush from mux_chr_read to mux_chr_can_read. While the >> latter is called periodically, the former will only be invoked when new >> characters arrive at the back-end. This caused problems to front-end >> drivers whenever they were unable to read data immediately, e.g. >> virtio-console attached to stdio. > > This should help ny s390 virtio console issue, right? :) I'll try it out asap, worst case that might take until the weekend. I think you already tried and still found some scenarios broken (we still need to understand them IIRC). However, this one fixes at least those virtio-console scenarios I tested (with x86 guests). Jan -- Siemens AG, Corporate Technology, CT T DE IT 1 Corporate Competence Center Embedded Linux