From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:41812) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Z7ayy-0004JL-Qx for qemu-devel@nongnu.org; Tue, 23 Jun 2015 23:04:13 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Z7ayx-0002NL-So for qemu-devel@nongnu.org; Tue, 23 Jun 2015 23:04:12 -0400 Date: Wed, 24 Jun 2015 11:04:03 +0800 From: Fam Zheng Message-ID: <20150624030403.GA19177@ad.nay.redhat.com> References: <1433215322-23529-1-git-send-email-famz@redhat.com> <1433215322-23529-3-git-send-email-famz@redhat.com> <20150616160736.GD4958@stefanha-thinkpad.redhat.com> <20150624024747.GC1264@ad.nay.redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20150624024747.GC1264@ad.nay.redhat.com> Subject: Re: [Qemu-devel] [Qemu-block] [PATCH v2 02/13] block: Introduce bdrv_lock and bdrv_unlock API List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Stefan Hajnoczi Cc: Paolo Bonzini , Stefan Hajnoczi , qemu-devel@nongnu.org, qemu-block@nongnu.org On Wed, 06/24 10:47, Fam Zheng wrote: > On Tue, 06/16 17:07, Stefan Hajnoczi wrote: > > On Tue, Jun 02, 2015 at 11:21:51AM +0800, Fam Zheng wrote: > > > +/** > > > + * bdrv_lock: > > > + * > > > + * Begin a temporary exclusive accessing by locking the BDS. > > > + */ > > > +void bdrv_lock(BlockDriverState *bs); > > > + > > > +/** > > > + * bdrv_unlock: > > > + * > > > + * End a exclusive accessing. > > > + */ > > > +void bdrv_unlock(BlockDriverState *bs); > > > > This documentation is missing important points: > > > > 1. Does AioContext need to be held by the caller? (Yes) > > Yes. > > > > > 2. Is this about thread safety? (No, it's about exclusive access to a > > BDS *within* the AioContext.) > > As it has to quiesce iothreads as well (for now it's even more urgent than s/iothreads/ioeventfd/ > exclusive access within the same AioContext), I'd rather take it as yes. > > Paolo, please correct me. > > BTW, is there any semantics in here that we can use for multiqueue block layer? > > Fam > >