From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43)
	id 1MALUk-0003cl-FR
	for qemu-devel@nongnu.org; Sat, 30 May 2009 06:08:54 -0400
Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43)
	id 1MALUf-0003Y6-Pz
	for qemu-devel@nongnu.org; Sat, 30 May 2009 06:08:54 -0400
Received: from [199.232.76.173] (port=44189 helo=monty-python.gnu.org)
	by lists.gnu.org with esmtp (Exim 4.43) id 1MALUf-0003Xr-4X
	for qemu-devel@nongnu.org; Sat, 30 May 2009 06:08:49 -0400
Received: from verein.lst.de ([213.95.11.210]:46184)
	by monty-python.gnu.org with esmtps
	(TLS-1.0:DHE_RSA_3DES_EDE_CBC_SHA1:24) (Exim 4.60)
	(envelope-from <hch@lst.de>) id 1MALUe-0003GO-Kc
	for qemu-devel@nongnu.org; Sat, 30 May 2009 06:08:48 -0400
Date: Sat, 30 May 2009 12:08:42 +0200
From: Christoph Hellwig <hch@lst.de>
Subject: Re: [Qemu-devel] fix bdrv_read/write_em and qemu_aio_flush
Message-ID: <20090530100842.GA28053@lst.de>
References: <20090528163309.GJ20464@random.random>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20090528163309.GJ20464@random.random>
List-Id: qemu-devel.nongnu.org
List-Unsubscribe: <http://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.gnu.org/pipermail/qemu-devel>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <http://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: Andrea Arcangeli <aarcange@redhat.com>
Cc: qemu-devel@nongnu.org

On Thu, May 28, 2009 at 06:33:10PM +0200, Andrea Arcangeli wrote:
> Hello,
> 
> the debug code in my ide_dma_cancel patch (not yet included upstream)
> made us notice that when qemu_aio_flush returns, there are still
> pending aio commands that waits to complete. Auditing the code I found
> strange stuff like the fact qemu_aio_waits does nothing if there's an
> unrelated (no aio related) bh executed. And I think I found the reason
> of why there was still pending aio when qemu_aio_flush because
> qemu_aio_wait does a lot more than wait, it can start aio, and if the
> previous ->io_flush returned zero, the loop ends and ->io_flush isn't
> repeated. The fact an unrelated bh can make qemu_aio_wait a noop seems
> troublesome for all callers that aren't calling qemu_aio_wait in a
> loop like qemu_aio_flush, so I preferred to change those callers to a
> safer qemu_aio_flush in case the bh executed generates more pending
> I/O. What you think about this patch against qemu git?

Looks good to me.  In my unsubmitted aio support patches for qemu-io
I had to call qemu_aio_wait at least twice to get aio requests reliably
completed, but with this patch and calling qemu_aio_flush it always
completes all requests.