From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1JO78W-0006iU-FT for qemu-devel@nongnu.org; Sun, 10 Feb 2008 03:02:04 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1JO78U-0006dk-NZ for qemu-devel@nongnu.org; Sun, 10 Feb 2008 03:02:03 -0500 Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1JO78U-0006dN-GU for qemu-devel@nongnu.org; Sun, 10 Feb 2008 03:02:02 -0500 Received: from mx20.gnu.org ([199.232.41.8]) by monty-python.gnu.org with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1JO78T-0002yQ-Rv for qemu-devel@nongnu.org; Sun, 10 Feb 2008 03:02:02 -0500 Received: from fg-out-1718.google.com ([72.14.220.152]) by mx20.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1JO78S-0003zi-C3 for qemu-devel@nongnu.org; Sun, 10 Feb 2008 03:02:00 -0500 Received: by fg-out-1718.google.com with SMTP id e12so3476509fga.8 for ; Sun, 10 Feb 2008 00:01:58 -0800 (PST) Message-ID: Date: Sun, 10 Feb 2008 10:01:58 +0200 From: "Blue Swirl" Subject: Re: [Qemu-devel] Re: 2.6.24 says "serial8250: too much work for irq4" a lot. In-Reply-To: <47AE1CC5.10700@zytor.com> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <200802051455.10831.rob@landley.net> <200802071413.45085.rob@landley.net> <47AB75EB.3040405@zytor.com> <200802082349.34301.rob@landley.net> <47AD524C.2070508@zytor.com> <47AE1CC5.10700@zytor.com> Reply-To: qemu-devel@nongnu.org List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: "H. Peter Anvin" Cc: qemu-devel@nongnu.org On 2/9/08, H. Peter Anvin wrote: > Blue Swirl wrote: > >> > >> If you look at the patch, there are no timing dependencies; the only > >> parameter is the depth of the virtual queue. The exhaustion is > >> completely controlled by target OS access patterns. > > > > Thanks, this clarified the difference. But I'll rephrase my original comment: > > > > The patch looks OK, but the simulated FIFO exhaustion should benefit > > all devices, as > > discussed here: > > http://lists.gnu.org/archive/html/qemu-devel/2007-12/msg00283.html > > The difference is you *can't* do that in a general layer. What makes you think that is impossible? Just move the serial_clear_burst to vl.c under name chr_clear_burst, move burst_len to CharDriverState and introduce a new function in vl.c that contains the burst length check. This is functionally identical to your patch. For 100% compatibility, the init functions could be changed so that only PC serial is affected, but I think all character devices would benefit from this. Also win2k install hack in ide.c seems to be related to this problem, so even more generic solution would be desirable.