On Sunday 10 February 2008, Blue Swirl wrote: > On 2/9/08, H. Peter Anvin <[EMAIL PROTECTED]> 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
