From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from eggs.gnu.org ([208.118.235.92]:41892)
	by lists.gnu.org with esmtp (Exim 4.71)
	(envelope-from <stefanha@redhat.com>) id 1Tgr4g-00027n-RI
	for qemu-devel@nongnu.org; Fri, 07 Dec 2012 01:06:17 -0500
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
	(envelope-from <stefanha@redhat.com>) id 1Tgr4e-0001Me-Es
	for qemu-devel@nongnu.org; Fri, 07 Dec 2012 01:06:14 -0500
Received: from mx1.redhat.com ([209.132.183.28]:36188)
	by eggs.gnu.org with esmtp (Exim 4.71)
	(envelope-from <stefanha@redhat.com>) id 1Tgr4e-0001MZ-65
	for qemu-devel@nongnu.org; Fri, 07 Dec 2012 01:06:12 -0500
Date: Fri, 7 Dec 2012 07:06:08 +0100
From: Stefan Hajnoczi <stefanha@redhat.com>
Message-ID: <20121207060608.GB5244@stefanha-thinkpad.redhat.com>
References: <1354740430-22452-1-git-send-email-stefanha@redhat.com>
	<1354740430-22452-11-git-send-email-stefanha@redhat.com>
	<50C04ADB.9040402@redhat.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <50C04ADB.9040402@redhat.com>
Subject: Re: [Qemu-devel] [PATCH v5 10/11] dataplane: add virtio-blk data
	plane code
List-Id: <qemu-devel.nongnu.org>
List-Unsubscribe: <https://lists.nongnu.org/mailman/options/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.nongnu.org/archive/html/qemu-devel>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <https://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: Paolo Bonzini <pbonzini@redhat.com>
Cc: Kevin Wolf <kwolf@redhat.com>, Anthony Liguori <aliguori@us.ibm.com>, "Michael S. Tsirkin" <mst@redhat.com>, qemu-devel@nongnu.org, Blue Swirl <blauwirbel@gmail.com>, khoa@us.ibm.com, asias@redhat.com

On Thu, Dec 06, 2012 at 08:35:55AM +0100, Paolo Bonzini wrote:
> Il 05/12/2012 21:47, Stefan Hajnoczi ha scritto:
> > +
> > +/* Block until pending requests have completed
> > + *
> > + * The vring continues to be serviced so ensure no new requests will be added
> > + * to avoid races.
> > + */
> > +void virtio_blk_data_plane_drain(VirtIOBlockDataPlane *s)
> > +{
> > +    qemu_mutex_lock(&s->num_reqs_lock);
> > +    while (s->num_reqs > 0) {
> > +        qemu_cond_wait(&s->no_reqs_cond, &s->num_reqs_lock);
> > +    }
> > +    qemu_mutex_unlock(&s->num_reqs_lock);
> > +}
> 
> Hi Stefan,
> 
> so this was not changed from v4?

BTW I should go into slightly more detail about why I stopped short of
implementing the notify+join approach.

notify+join means stopping the event loop and data plane thread so
that the caller is sure that virtio-blk-data-plane is quiesced.

Unfortunately this doesn't map nicely to bdrv_drain_all() where the
caller has the global mutex, quiesces I/O, and then performs a critical
operation.  I/O resumes after the caller returns or releases the global
mutex:

bdrv_drain_all();
critical_operation();
return;
/* now it's okay to process I/O again */

We cannot use notify+join here because bdrv_drain_all() would stop the
data plane thread but nothing restarts it!

Perhaps we'd need a "resume" call after the critical operation so that
the data plane thread is restarted - but this sounds invasive and is a
departure from how existing I/O and emulated devices work.

Stefan