From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:46161) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aK639-0005HM-L9 for qemu-devel@nongnu.org; Fri, 15 Jan 2016 10:12:28 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aK637-0006CO-9U for qemu-devel@nongnu.org; Fri, 15 Jan 2016 10:12:27 -0500 Received: from mx1.redhat.com ([209.132.183.28]:53069) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aK637-0006CD-44 for qemu-devel@nongnu.org; Fri, 15 Jan 2016 10:12:25 -0500 Received: from int-mx09.intmail.prod.int.phx2.redhat.com (int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22]) by mx1.redhat.com (Postfix) with ESMTPS id D26ACC07582F for ; Fri, 15 Jan 2016 15:12:24 +0000 (UTC) From: Paolo Bonzini Date: Fri, 15 Jan 2016 16:12:05 +0100 Message-Id: <1452870739-28484-3-git-send-email-pbonzini@redhat.com> In-Reply-To: <1452870739-28484-1-git-send-email-pbonzini@redhat.com> References: <1452870739-28484-1-git-send-email-pbonzini@redhat.com> Subject: [Qemu-devel] [PATCH 02/16] aio: do not really acquire/release the main AIO context List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: qemu-devel@nongnu.org Cc: stefanha@redhat.com 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 --- async.c | 12 ++++++++++-- 1 file changed, 10 insertions(+), 2 deletions(-) diff --git a/async.c b/async.c index e106072..b3efd3c 100644 --- a/async.c +++ b/async.c @@ -368,10 +368,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); + } } -- 2.5.0