So, splicing in a bottom half unmoored monitor commands from the main
loop. We weren't aware of that, as our commit messages show.
I guess the commands themselves don't care; all they need is the BQL.
However, did we unwittingly change what can get blocked? Before,
monitor commands could block only the main thread. Now they can also
block vCPU threads. Impact?
Monitor commands could always block vCPU threads through the BQL(*). However, aio_poll() only runs in the vCPU threads in very special cases; typically associated to resetting a device which causes a blk_drain() on the device's BlockBackend. So it is not a performance issue.
However, liberal reuse of the main block layer AioContext could indeed be a *correctness* issue. I need to re-read Fiona's report instead of stopping at the first three lines because it's the evening. :)
Paolo
(*) Some of you may remember that when migration ran under the BQL it was also a very effective way to ensure that vCPU threads were slowed down, so it helped migration converge. Once that hurdle was removed, we had to add manual sleeping in the vCPU threads!