qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: "Blue Swirl" <blauwirbel@gmail.com>
To: "H. Peter Anvin" <hpa@zytor.com>
Cc: qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] Re: 2.6.24 says "serial8250: too much work for irq4" a lot.
Date: Sun, 10 Feb 2008 10:01:58 +0200	[thread overview]
Message-ID: <f43fc5580802100001u13dcfab3l6551ff91522e0e4c@mail.gmail.com> (raw)
In-Reply-To: <47AE1CC5.10700@zytor.com>

On 2/9/08, H. Peter Anvin <hpa@zytor.com> 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.

  reply	other threads:[~2008-02-10  8:02 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <200802051455.10831.rob@landley.net>
     [not found] ` <47A8D00F.9040803@zytor.com>
2008-02-06  0:43   ` [Qemu-devel] Re: 2.6.24 says "serial8250: too much work for irq4" a lot Rob Landley
     [not found] ` <200802071413.45085.rob@landley.net>
     [not found]   ` <47AB75EB.3040405@zytor.com>
2008-02-09  5:49     ` Rob Landley
2008-02-09  7:04       ` Blue Swirl
2008-02-09  7:12         ` H. Peter Anvin
2008-02-09 11:15           ` Blue Swirl
2008-02-09 21:36             ` H. Peter Anvin
2008-02-10  8:01               ` Blue Swirl [this message]
2008-02-10 11:26                 ` Paul Brook
2008-03-11 23:51                   ` Aurelien Jarno

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=f43fc5580802100001u13dcfab3l6551ff91522e0e4c@mail.gmail.com \
    --to=blauwirbel@gmail.com \
    --cc=hpa@zytor.com \
    --cc=qemu-devel@nongnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).