On Fri, Jan 15, 2016 at 04:12:08PM +0100, Paolo Bonzini wrote: > @@ -120,9 +117,17 @@ Block layer code must therefore expect to run in an > IOThread and avoid using > old APIs that implicitly use the main loop. See the "How to program for > IOThreads" above for information on how to do that. > > -If main loop code such as a QMP function wishes to access a BlockDriverState > it > -must first call aio_context_acquire(bdrv_get_aio_context(bs)) to ensure the > -IOThread does not run in parallel. > +If main loop code such as a QMP function wishes to access a BlockDriverState > +it must first call aio_context_acquire(bdrv_get_aio_context(bs)) to ensure > +that callbacks in the IOThread do not run in parallel. > + > +Code running in the monitor typically uses bdrv_drain() to ensure that > +past requests from the guest are completed. When a block device is > +running in an IOThread, the IOThread can also process requests from > +the guest (via ioeventfd). These requests have to be blocked with > +aio_disable_clients() before calling bdrv_drain(). You can then reenable > +guest requests with aio_enable_clients() before finally releasing the > +AioContext and completing the monitor command.
This is outdated. Monitor commands do this: bdrv_drained_begin() -> ... -> bdrv_drain() -> ... -> bdrv_drained_end() > @@ -110,6 +111,8 @@ static void *test_acquire_thread(void *opaque) > qemu_mutex_lock(&data->start_lock); > qemu_mutex_unlock(&data->start_lock); > > + g_usleep(500000); Sleep?
signature.asc
Description: PGP signature
