This doesn’t seem to be specified anywhere, but is something we probably want to be clear. I believe it is reasonable to implicitly assume that callbacks are run in the current thread (unless explicitly noted otherwise), so codify that assumption.
Some implementations don’t actually fulfill this contract yet. The next patches should rectify that. Note: I don’t know of any user-visible bugs produced by not running AIO callbacks in the original context. AIO functionality is generally mapped to coroutines through the use of bdrv_co_io_em_complete(), which can run in any AioContext, and will always wake the yielding coroutine in its original context. The only benefit here is that running bdrv_co_io_em_complete() in the original context will make that aio_co_wake() most likely a simpler qemu_coroutine_enter() instead of scheduling the wakeup through AioContext.co_schedule_bh. Signed-off-by: Hanna Czenczek <[email protected]> --- include/block/block_int-common.h | 7 ++++++- 1 file changed, 6 insertions(+), 1 deletion(-) diff --git a/include/block/block_int-common.h b/include/block/block_int-common.h index 034c0634c8..a584f20aea 100644 --- a/include/block/block_int-common.h +++ b/include/block/block_int-common.h @@ -508,7 +508,12 @@ struct BlockDriver { BlockDriverState *bs, BlockdevAmendOptions *opts, bool force, Error **errp); - /* aio */ + /* + * AIO + * The given completion callback will be run in the same AioContext as the + * one in which the AIO function was called. + */ + BlockAIOCB * GRAPH_RDLOCK_PTR (*bdrv_aio_preadv)(BlockDriverState *bs, int64_t offset, int64_t bytes, QEMUIOVector *qiov, BdrvRequestFlags flags, BlockCompletionFunc *cb, void *opaque); -- 2.51.0
