Am 02.07.2012 10:57, schrieb Peter Crosthwaite: > On Mon, Jul 2, 2012 at 6:50 PM, Stefan Hajnoczi <stefa...@gmail.com> wrote: >> On Fri, Jun 29, 2012 at 12:51 PM, Peter Crosthwaite >> <peter.crosthwa...@petalogix.com> 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