[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] Docs for and debugging of Asynchronous I/O
From: |
Stefan Hajnoczi |
Subject: |
Re: [Qemu-devel] Docs for and debugging of Asynchronous I/O |
Date: |
Tue, 20 Jul 2010 21:57:14 +0100 |
On Tue, Jul 20, 2010 at 7:34 PM, Ot ten Thije <address@hidden> wrote:
> Hello,
> I am working on fixing the savevm/loadvm functionality in the Android
> emulator, and the two issues I've encountered so far both appear to stem
> from the asynchronous I/O (AIO) code. In both cases, the emulator busy-waits
> indefinitely for an operation that never signals completion.
> Unfortunately I am not really familiar with AIO, so I was hoping one of the
> emulator devs could point me some resources (design docs, general
> introduction, etc.). I've done some searching myself and found some docs for
> the Linux kernel AIO implementation
> (http://lse.sourceforge.net/io/aio.html), but I'm not sure to what extent it
> applies to the QEMU code.
qemu.git has support for Linux AIO, which you linked to. The code for
that is in linux-aio.c. But by default it uses a thread pool to
perform the normal blocking syscalls out-of-line with respect to the
VM, see posix-aio-compat.c.
Both of these aio backends are driven from the QEMU block layer, which
provides a block device interface that several drivers implement
(qcow2, raw, ...). bdrv_aio_readv() and bdrv_aio_writev() are the
main entry points.
I wonder if you can track down the sequence of block interface calls
that causes the hang. Then it should be possible to construct a
simple test case and even try it again qemu.git/master.
> Tips for debugging AIO would also be greatly appreciated. I can trace the
> execution until I am within the (emulated) device driver (i.e.
> block/qcow2.c:qcow_aio_writev()), but haven't been able to pinpoint the
> exact location where the actual async call is made. This makes it difficult
> to identify the code that should signal completion back to the main process
> (and apparently fails to do so). I know this code is called though, because
> some asynchronous calls *do* signal completion.
> I realize that the Android emulator is a rather heavy fork of QEMU, so
> giving specific advice will probably be difficult. However, the overall
> approach is still the same, so I hope you can help me get a better
> understanding of that.
Have you checked QEMU's git log to see if there are fixes in qemu.git
that could fix this for the Android emulator?
Stefan
>
> Ot ten Thije