Re: [Qemu-devel] Hard disk support is broken in Windows 98SE guest

["Leonardo Reiter" <lreiter76@gmail.com>]

On 10/3/07, Victor Shkamerda <vvs@auto.bnm.org> wrote:
> Hello,
>
> >>> On 10/2/2007 at 7:43 PM, in message <20071002164337.GH16772@networkno.de>,
> Thiemo Seufer <ths@networkno.de> wrote:
> > I don't have such a system for tests. Can you narrow down which CVS
> > commit broke it?
>
> hw/ide.c 1.64 works, version 1.65 doesn't. Only BIOS operations seems to be affected, so it may be BIOS fault after all. You can use FreeDOS for testing, it doesn't install too.
>

The problem seems to be that the BIOS does not wait for the previous
write to complete before trying the next one.  It's not clear to me
whether this needs to be fixed in the BIOS or in hw/ide.c.  One
correct fix may be to have ide_sector_write set BUSY_STAT and then let
the AIO callback function set the status to READY_STAT, but this
definitely does not work well with the BOCHS BIOS.  Here's a hack that
seems to work, but it's pretty ugly:

Index: hw/ide.c
===================================================================
RCS file: /cvsroot/qemu/qemu/hw/ide.c,v
retrieving revision 1.69
diff -a -u -r1.69 ide.c
--- hw/ide.c    17 Sep 2007 08:09:47 -0000      1.69
+++ hw/ide.c    3 Oct 2007 18:00:31 -0000
@@ -900,7 +900,9 @@
     if(bm == NULL) {
        bm = qemu_mallocz(sizeof(BMDMAState));
        s->bmdma = bm;
-    }
+    } else if (bm->aiocb != NULL)
+        qemu_aio_wait();
+
     bm->ide_if = s;
     bm->dma_cb = ide_sector_write_aio_cb;


The danger here is that the AIO signal came in already by the time we
call qemu_aio_wait() (but bm->aiocb was not called yet), which is
pretty unlikely, but I think it could trigger a deadlock.  I don't
think that's correct, but the fact is the BIOS assumes that the write
is done by the time it does another write.  That seems to step on the
io_buffer, which is part of the asynchronous write that is pending.
Another solution may be to use a separate buffer for the write, but
then you have a copy and you have to hold on to the memory until the
write finishes.  I think ultimately the correct fix is in the BIOS -
perhaps a spinlock on BUSY_STAT like it does after seeks, or something
like that.  Maybe someone who knows more about this can comment.
Please note that I am not asking for the above patch to be committed,
just putting it out there as food for thought.  It's probably (likely)
the wrong approach.

The reason the old win2k-hack worked, even if the BIOS didn't wait for
the IDE interrupt to write the next buffer, is because the actual host
write() was synchronous and the IO buffer could be safely stepped on
at any point after that.  AIO writes have to hold on to the buffer
until they complete (see man page for aio_write).

- Leo Reiter