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? Regards, Peter > Stefan