Re: [Qemu-devel] Re: 2.6.24 says "serial8250: too much work for irq4" a lot.

[Paul Brook]

On Sunday 10 February 2008, Blue Swirl wrote:
> On 2/9/08, H. Peter Anvin <address@hidden> 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? 

IIUC the proposed patch makes the serial driver return an empty FIFO exactly 
once, them immediately continue receiving data. Throughput should be 
approximately the same, you've just got a bit of extra overhead to process 
the additional interrupts.  This is very different to the previous patch 
which did time-based throughput limiting.

You can't do this in generic code because there's no way to guess when the 
guest os has seen the FIFO empty condition. The best you can do is pause for 
some arbitrary length of time, which is both unreliable (the guest OS may not 
have got to far enough yet, especially if the host machine is heavily 
loaded), and has a significant negative impact on throughput.

> Also win2k install hack in ide.c seems to be related to this problem,
> so even more generic solution would be desirable.

IIUC the win2k hack is an actual timing problem. The win2k IDE drivers are 
buggy, and fall over if the drive responds too soon.

Paul