From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:53383) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QoGFS-0004aq-Rn for qemu-devel@nongnu.org; Tue, 02 Aug 2011 10:47:11 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1QoGFR-0003fT-5u for qemu-devel@nongnu.org; Tue, 02 Aug 2011 10:47:10 -0400 Received: from mx1.redhat.com ([209.132.183.28]:61012) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QoGFQ-0003f9-VA for qemu-devel@nongnu.org; Tue, 02 Aug 2011 10:47:09 -0400 Message-ID: <4E380E9B.5090600@redhat.com> Date: Tue, 02 Aug 2011 16:50:03 +0200 From: Kevin Wolf MIME-Version: 1.0 References: <1311680948-7648-1-git-send-email-kwolf@redhat.com> <4E38084C.6010601@redhat.com> In-Reply-To: <4E38084C.6010601@redhat.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH 00/10] block: Coroutine support List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Avi Kivity Cc: stefanha@gmail.com, qemu-devel@nongnu.org Am 02.08.2011 16:23, schrieb Avi Kivity: > On 07/26/2011 02:48 PM, Kevin Wolf wrote: >> Depends on Stefan's latest coroutine patches. This series makes qcow and qcow2 >> take advantage of the new coroutine infrastructure. Both formats used >> synchronous operations for accessing their metadata and blocked the guest CPU >> during that time. With coroutines, the I/O will happen asynchronously in the >> background and the CPU won't be blocked any more. >> > > Do you plan to convert qcow2 to a fully synchronous design? > > IMO that will make it more maintainable. Cancellation will need some > thought, though. After this patch series, all interesting paths are free of callbacks (I assume this is what you mean by synchronous?). The only thing I can see that is left is qcow2_aio_flush. What is required are some cleanups that eliminate things that still look like AIO code, and yes, that's something that I want to have. Frediano has posted some patches which I haven't fully reviewed yet, but the qcow1 RFC he posted was definitely a step in the right direction. Regarding cancellation, I don't know any driver that really does what it's supposed to do. There are basically two ways of implementing it in current code: Either by completing the request instead of cancelling, or it's broken. I'd suggest that we implement waiting for completion as a generic function in the block layer and be done with it (actually this is what happens with bdrv_aio_co_cancel_em, it just could be a bit finer grained). Kevin