From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:44548) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YpyJX-0007xS-IP for qemu-devel@nongnu.org; Wed, 06 May 2015 08:20:36 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YpyJP-00074s-VB for qemu-devel@nongnu.org; Wed, 06 May 2015 08:20:35 -0400 Date: Wed, 6 May 2015 20:20:23 +0800 From: Fam Zheng Message-ID: <20150506122023.GD9991@ad.nay.redhat.com> References: <1430911419-8256-1-git-send-email-famz@redhat.com> <1430911419-8256-7-git-send-email-famz@redhat.com> <554A040B.7030108@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <554A040B.7030108@redhat.com> Subject: Re: [Qemu-devel] [RFC PATCH 6/7] virtio-blk: Don't handle output when there is "device IO" op blocker List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Paolo Bonzini Cc: Kevin Wolf , qemu-block@nongnu.org, armbru@redhat.com, jcody@redhat.com, qemu-devel@nongnu.org, mreitz@redhat.com, Stefan Hajnoczi On Wed, 05/06 14:07, Paolo Bonzini wrote: > > > On 06/05/2015 13:23, Fam Zheng wrote: > > virtio-blk now listens to op blocker change of the associated block > > backend. > > > > Up on setting op blocker on BLOCK_OP_TYPE_DEVICE_IO: > > > > non-dataplane: > > 1) Set VirtIOBlock.paused > > 2) In virtio_blk_handle_output, do nothing if VirtIOBlock.paused > > > > dataplane: > > 1) Clear the host event notifier > > 2) In handle_notify, do nothing if VirtIOBlock.paused > > > > Up on removing the op blocker: > > > > non-dataplane: > > 1) Clear VirtIOBlock.paused > > 2) Schedule a BH on the AioContext of the backend, which calls > > virtio_blk_handle_output, so that the previous unhandled kicks can > > make progress > > > > dataplane: > > 1) Set the host event notifier > > 2) Notify the host event notifier so that unhandled events are > > processed > > > > Signed-off-by: Fam Zheng > > Does non-dataplane need to do anything, since it uses iohandlers rather > than aio_set_event_notifier_handler? I guess it's not for this specific bug. See this as an attempt on a general purpose "pause" mechanism to the device in investment for the future, for example, bdrv_aio_drain. ;-) I can drop it in v2 if you think the idea is not very helpful. Fam