From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:50154) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1azoM2-0001tv-Rg for qemu-devel@nongnu.org; Mon, 09 May 2016 12:48:30 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1azoLw-0006uv-QC for qemu-devel@nongnu.org; Mon, 09 May 2016 12:48:21 -0400 Received: from mx1.redhat.com ([209.132.183.28]:40261) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1azoLw-0006up-Jx for qemu-devel@nongnu.org; Mon, 09 May 2016 12:48:16 -0400 Received: from int-mx14.intmail.prod.int.phx2.redhat.com (int-mx14.intmail.prod.int.phx2.redhat.com [10.5.11.27]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 2B2362637 for ; Mon, 9 May 2016 16:48:16 +0000 (UTC) References: <1460384056-29494-1-git-send-email-stefanha@redhat.com> From: Paolo Bonzini Message-ID: <5730BF4C.2080800@redhat.com> Date: Mon, 9 May 2016 18:48:12 +0200 MIME-Version: 1.0 In-Reply-To: <1460384056-29494-1-git-send-email-stefanha@redhat.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [RFC for-2.7] block: keep AioContext pointer in BlockBackend List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Stefan Hajnoczi , qemu-devel@nongnu.org Cc: Max Reitz , Kevin Wolf On 11/04/2016 16:14, Stefan Hajnoczi wrote: > 1. BlockBackend falls back to the QEMU main loop AioContext when there > is no root BlockDriverState. This means the drive loses its > AioContext during media change and would break dataplane. > > 2. BlockBackend state used from multiple threads has no lock. Race > conditions will creep in as functionality is moved from > BlockDriverState to BlockBackend due to the absense of a lock. The > monitor cannot access BlockBackend state safely while an IOThread is > also accessing the state. > > Both issue #1 and #2 are mostly theoretical at the moment. I haven't > figured out a way to trigger #1 with virtio-blk (does not support media > change) or virtio-scsi (blocks the eject operation). #2 may be possible > with block accounting statistics in BlockBackend but I'm not aware of a > crash that can be triggered. I'm not sure I agree with #2, as we should move away for the super-coarse AioContext lock (it is heavyweight and it doesn't play well with multiqueue). Atomics can be used for statistics, while the time-based accounting probably should be made optional because it's heavy-weight and hard to scale. But I do agree with #1, so the idea seems good. Paolo