From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:36073) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Z7h5o-0007jY-4E for qemu-devel@nongnu.org; Wed, 24 Jun 2015 05:35:41 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Z7h5n-0002jg-4T for qemu-devel@nongnu.org; Wed, 24 Jun 2015 05:35:40 -0400 Date: Wed, 24 Jun 2015 10:35:30 +0100 From: Stefan Hajnoczi Message-ID: <20150624093530.GA7454@stefanha-thinkpad.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: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="u3/rZRmxL6MmkK24" 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: Fam Zheng Cc: Stefan Hajnoczi , qemu-devel@nongnu.org, qemu-block@nongnu.org, Paolo Bonzini --u3/rZRmxL6MmkK24 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Jun 24, 2015 at 10:47:47AM +0800, 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: > > 2. Is this about thread safety? (No, it's about exclusive access to a > > BDS *within* the AioContext.) >=20 > As it has to quiesce iothreads as well (for now it's even more urgent than > exclusive access within the same AioContext), I'd rather take it as yes. This mechanism is not about threads and it is also not thread-safe (the caller must acquire AioContext themselves). The mechanism is about notifying the users of a drive that no requests should be submitted. > BTW, is there any semantics in here that we can use for multiqueue block = layer? The callback to remove/add ioeventfd is needed by multiqueue in the same way as dataplane. I think the actual multiqueue I/O will need to be more fine-grained because the goal is to process I/O requests in parallel and independently. Multiqueue should not require exclusive access (which this mechanism provides) - that would defeat the point of multiqueue. Stefan --u3/rZRmxL6MmkK24 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAEBAgAGBQJVinniAAoJEJykq7OBq3PIrPcH/Ajsq4ZHnQ8d0DojZb9WNiBg xcyff+J5OAfB/C71jstN/lQdSEXpicRJVo+AFFf/z1v3Nj3qUUD0NMNiW6FBAwrI MgN2kRSxNL3vPu9aZdrlsrgReXaMGAB+UNfJzunh+ULtCDoKxL91VIouAVvGmVtW s6zFW+vfrWKNuQ8l7lATEB6n74Hf0Cu5Zo3p+404uJwsah8Y7qdR22SnLXeLWfk0 Lyu1mhL6jCeMgXkjunCcWbaTnOU/sheCtTyUoxPnw6gHBDWcGJ5V7TV+AlUFkC6O Lnl0oSjLGd6HUhdxO+9WAirFXmWJLphAmRH2ZO3YbC4WAgIxUa9JuXPEFIDIF5A= =7e4G -----END PGP SIGNATURE----- --u3/rZRmxL6MmkK24--