Kouya Shimura writes ("Re: [Xen-devel] Windows Bug Check 0x101 issue"):
> Here is a revised patch. Is this a good fix?
Sadly not.
There are two problems:
One is that the qemu block driver abstraction does not support
asynchronous flush. To fix this problem, it is necessary to add a new
entrypoint for block drivers (and a new fixup wrapper in block.c to
deal with drivers which only support the synch entrypoint).
The other is that the IDE flush necessarily blocks. The IDE command
being used here is an IO write which instructs the disk to flush and
which the guest operating system expects to complete only when the
flush is done. Windows is evidently expecting to successfully receive
a timer interrupt on another CPU while the first one is blocked on the
IO operation - but as I understand it our emulation and threading
model doesn't permit this.
As a workaround, perhaps we should provide a way for the Xen
administrator to turn this operation into a nonblocking lazy flush
request ?
> +void bdrv_aio_flush(BlockDriverState *bs, 
> + BlockDriverCompletionFunc *cb, void *opaque)
> +{
> + RawAIOCB *acb;
> +
> + acb = raw_aio_setup(bs, 0, NULL, 0, cb, opaque);
> + if (!acb)
> + return;
> + if (aio_fsync(O_SYNC, &acb->aiocb) < 0)
> + qemu_aio_release(acb);
> +}
This is quite wrong, I'm afraid. You absolutely must not call through
to raw_aio_* functions from block.c in this way. This will break for
all block backends other than raw.
Ian.
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel