effd60c878
monitor_qmp_dispatcher_co() runs in the iohandler AioContext that is not
polled during nested event loops. The coroutine currently reschedules
itself in the main loop's qemu_aio_context AioContext, which is polled
during nested event loops. One known problem is that QMP device-add
calls drain_call_rcu(), which temporarily drops the BQL, leading to all
sorts of havoc like other vCPU threads re-entering device emulation code
while another vCPU thread is waiting in device emulation code with
aio_poll().
Paolo Bonzini suggested running non-coroutine QMP handlers in the
iohandler AioContext. This avoids trouble with nested event loops. His
original idea was to move coroutine rescheduling to
monitor_qmp_dispatch(), but I resorted to moving it to qmp_dispatch()
because we don't know if the QMP handler needs to run in coroutine
context in monitor_qmp_dispatch(). monitor_qmp_dispatch() would have
been nicer since it's associated with the monitor implementation and not
as general as qmp_dispatch(), which is also used by qemu-ga.
A number of qemu-iotests need updated .out files because the order of
QMP events vs QMP responses has changed.
Solves Issue #1933.
Cc: qemu-stable@nongnu.org
Fixes:
|
||
---|---|---|
.. | ||
avocado | ||
bench | ||
data | ||
decode | ||
docker | ||
fp | ||
guest-debug | ||
image-fuzzer | ||
include | ||
keys | ||
lcitool | ||
migration | ||
multiboot | ||
perf/block/qcow2 | ||
plugin | ||
qapi-schema | ||
qemu-iotests | ||
qtest | ||
rocker | ||
tcg | ||
tsan | ||
uefi-test-tools | ||
unit | ||
vm | ||
vmstate-static-checker-data | ||
dbus-vmstate-daemon.sh | ||
Makefile.include | ||
meson.build | ||
test-qht-par.c | ||
vhost-user-bridge.c |