From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:55132) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SlcYp-0002gS-B2 for qemu-devel@nongnu.org; Mon, 02 Jul 2012 05:04:54 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1SlcYh-0005La-Mb for qemu-devel@nongnu.org; Mon, 02 Jul 2012 05:04:46 -0400 Received: from mx1.redhat.com ([209.132.183.28]:21561) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SlcYh-0005LM-EF for qemu-devel@nongnu.org; Mon, 02 Jul 2012 05:04:39 -0400 Message-ID: <4FF16407.6030703@redhat.com> Date: Mon, 02 Jul 2012 11:04:07 +0200 From: Kevin Wolf MIME-Version: 1.0 References: <1340347459-29861-1-git-send-email-peter.crosthwaite@petalogix.com> <4FED6638.90703@redhat.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [RFC] block: Removed coroutine ownership assumption List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Peter Crosthwaite Cc: Peter Maydell , stefanha@linux.vnet.ibm.com, Stefan Hajnoczi , qemu-devel@nongnu.org, Markus Armbruster , edgar.iglesias@gmail.com, john.williams@petalogix.com Am 02.07.2012 10:57, schrieb Peter Crosthwaite: > On Mon, Jul 2, 2012 at 6:50 PM, Stefan Hajnoczi wrote: >> On Fri, Jun 29, 2012 at 12:51 PM, Peter Crosthwaite >> wrote: >>> BTW Yielding is one thing, but the elephant in the room here is >>> resumption of the coroutine. When AIO yields my coroutine I i need to >>> talk to AIO to get it unyielded (Stefans propsoed edit to my code). >>> What happens when tommorow something in QOM, or a device model or is >>> implemented with coros too? how do I know who yielded my routines and >>> what API to call re-enter it? >> >> Going back to what Kevin said, the qemu_aio_wait() isn't block layer >> specific and there will never be a requirement to call any other magic >> functions. >> >> QEMU is event-driven and you must pump events. If you call into >> another subsystem, be prepared to pump events so that I/O can make >> progress. It's an assumption that is so central to QEMU architecture >> that I don't see it as a problem. >> >> Once the main loop is running then the event loop is taken care of for >> you. But during startup you're in a different environment and need to >> pump events yourself. >> >> If we drop bdrv_read()/bdrv_write() this won't change. You'll have to >> call bdrv_co_readv()/bdrv_co_writev() and pump events. >> > > Just tracing bdrv_aio_read(), It bypasses the fastpath logic: > > . So a conversion of pflash to bdrv_aio_readv is a possible solution here. > > bdrv_aio_read -> bdrv_co_aio_rw_vector : > > static BlockDriverAIOCB *bdrv_co_aio_rw_vector (..) { > Coroutine *co; > BlockDriverAIOCBCoroutine *acb; > > ... > > co = qemu_coroutine_create(bdrv_co_do_rw); > qemu_coroutine_enter(co, acb); > > return &acb->common; > } > > No conditional on the qemu_coroutine_create. So it will always create > a new coroutine for its work which will solve my problem. All I need > to do is pump events once at the end of machine model creation. Any my > coroutines will never yield or get queued by block/AIO. Sound like a > solution? If you don't need the read data in your initialisation code, then yes, that would work. bdrv_aio_* will always create a new coroutine. I just assumed that you wanted to use the data right away, and then using the AIO functions wouldn't have made much sense. Kevin