From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:47193) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XaVQ7-0008T2-Ut for qemu-devel@nongnu.org; Sat, 04 Oct 2014 15:55:18 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XaVQ1-0004pE-Qf for qemu-devel@nongnu.org; Sat, 04 Oct 2014 15:55:11 -0400 Received: from mx1.redhat.com ([209.132.183.28]:26911) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XaVQ1-0004lx-KB for qemu-devel@nongnu.org; Sat, 04 Oct 2014 15:55:05 -0400 Message-ID: <54305092.3000606@redhat.com> Date: Sat, 04 Oct 2014 21:54:58 +0200 From: Max Reitz MIME-Version: 1.0 References: <1412182919-9550-1-git-send-email-stefanha@redhat.com> <1412182919-9550-8-git-send-email-stefanha@redhat.com> <542C583F.9010502@redhat.com> <20141002150851.GF6250@stefanha-thinkpad.redhat.com> In-Reply-To: <20141002150851.GF6250@stefanha-thinkpad.redhat.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH 07/11] block: let backup blockjob run in BDS AioContext List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Stefan Hajnoczi Cc: Kevin Wolf , Paolo Bonzini , Fam Zheng , qemu-devel@nongnu.org, Stefan Hajnoczi On 02.10.2014 17:08, Stefan Hajnoczi wrote: > On Wed, Oct 01, 2014 at 09:38:39PM +0200, Max Reitz wrote: >> On 01.10.2014 19:01, Stefan Hajnoczi wrote: >>> The backup block job must run in the BlockDriverState AioContext so that >>> it works with dataplane. >>> >>> The basics of acquiring the AioContext are easy in blockdev.c. >>> >>> The completion code in block/backup.c must call bdrv_unref() from the >>> main loop. Use block_job_defer_to_main_loop() to achieve that. >>> >>> Signed-off-by: Stefan Hajnoczi >>> --- >>> block/backup.c | 21 +++++++++++++++++++-- >>> blockdev.c | 23 ++++++++++++++++------- >>> 2 files changed, 35 insertions(+), 9 deletions(-) >> Hm, so, if I run a backup blockjob from one thread (which is not the main >> loop and not the BDS's AIO context) > That cannot happen. The blockjob always runs with the BDS AioContext > acquired - either because we explicitly did so in the main loop or > because the dataplane IOThread acquires it. > >> and try to cancel it or set its speed >> from another thread (e.g. the main loop), won't the blockjob hold the BDS's >> AIO context lock as long as it runs and making it impossible to interfere? > No, because of how the AioContext's RfifoLock lock works. > > It has a "contention callback" that kicks the aio_poll() loop. This > allows the QEMU monitor to acquire the lock whenever an IOThread is > blocked in poll(2). It uses an eventfd to force the IOThread out of > poll(2) and this happens automatically in aio_context_acquire(). > > See aio_context_new() and aio_rfifolock_cb(). Ah, okay, thank you for clarifying that. Reviewed-by: Max Reitz