On 2/1/22 10:08, Emanuele Giuseppe Esposito wrote:
+ * + * This function should never be used in the block layer, please + * instead refer to qemu_in_main_thread().
This function should never be used in the block layer, because unit tests, block layer tools and qemu-storage-daemon do not have a BQL.
Please instead refer to qemu_in_main_thread().
+ +/** + * qemu_in_main_thread: same as qemu_mutex_iothread_locked when + * softmmu/cpus.c implementation is linked. Otherwise this function + * checks that the current AioContext is the global AioContext + * (main loop). + * + * This is useful when checking that the BQL is held as a + * replacement of qemu_mutex_iothread_locked() usege in the + * block layer, since the former returns false when invoked by + * unit tests or other users like qemu-storage-daemon that end + * up using the stubs/iothread-lock.c implementation. + * + * This function should only be used in the block layer. + * Use this function to determine whether it is possible to safely + * access the block layer's globals. + */ +bool qemu_in_main_thread(void);
I think the reference to qemu_mutex_iothread_locked() complicates things. It's enough to explain the different policies in my opinion:
/** * qemu_in_main_thread: return whether it's possible to safely access * the global state of the block layer. * * Global state of the block layer is not accessible from I/O threads * or worker threads; only from threads that "own" the default * AioContext that qemu_get_aio_context() returns. For tests, block * layer tools and qemu-storage-daemon there is a designated thread that * runs the event loop for qemu_get_aio_context(), and that is the * main thread. * * For emulators, however, any thread that holds the BQL can act * as the block layer main thread; this will be any of the actual * main thread, the vCPU threads or the RCU thread. * * For clarity, do not use this function outside the block layer. */ Paolo
