| Message ID | 1455018374-4706-3-git-send-email-pbonzini@redhat.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
diff --git a/async.c b/async.c index d4dd2cc..d083564 100644 --- a/async.c +++ b/async.c @@ -369,10 +369,18 @@ void aio_context_unref(AioContext *ctx) void aio_context_acquire(AioContext *ctx) { - rfifolock_lock(&ctx->lock); + if (ctx == qemu_get_aio_context()) { + assert(qemu_mutex_iothread_locked()); + } else { + rfifolock_lock(&ctx->lock); + } } void aio_context_release(AioContext *ctx) { - rfifolock_unlock(&ctx->lock); + if (ctx == qemu_get_aio_context()) { + assert(qemu_mutex_iothread_locked()); + } else { + rfifolock_unlock(&ctx->lock); + } }
The main AIO context is used in many places that are not aware of AioContexts at all. bdrv_drain will soon do a release/acquire itself, which for the main AIO context would break because code calls bdrv_drain on it without acquiring anything. Very soon, bdrv will be ready for removal of aio_context_acquire from non-block-layer code. The idea is that the AioContext will be acquired by bdrv_*, and no one will care of what's running in the main I/O thread or in the dataplane thread. Even if there are two concurrent instances of the I/O thread, locks protect the data structures; this evolves naturally to the multiqueue case where there are multiple I/O threads touching the same BlockDriverState. When this happens, aio_context_acquire/release can go away, replaced by fine-grained locks, and this hack will also go away with it. Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> --- async.c | 12 ++++++++++-- 1 file changed, 10 insertions(+), 2 deletions(-)