From: Fiona Ebner <f.ebner@proxmox.com>
To: Stefan Hajnoczi <stefanha@redhat.com>, qemu-devel@nongnu.org
Cc: Paolo Bonzini <pbonzini@redhat.com>,
Kevin Wolf <kwolf@redhat.com>,
Markus Armbruster <armbru@redhat.com>,
Michael Roth <michael.roth@amd.com>,
qemu-block@nongnu.org, Hanna Reitz <hreitz@redhat.com>
Subject: Re: [PATCH 3/3] monitor: only run coroutine commands in qemu_aio_context
Date: Thu, 18 Jan 2024 16:47:25 +0100 [thread overview]
Message-ID: <06e2bccc-0a5b-4b58-9c4e-7b369f5d3076@proxmox.com> (raw)
In-Reply-To: <20240116190042.1363717-4-stefanha@redhat.com>
Am 16.01.24 um 20:00 schrieb Stefan Hajnoczi:
> 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.
>
> Fixes: 7bed89958bfbf40df9ca681cefbdca63abdde39d ("device_core: use drain_call_rcu in in qmp_device_add")
> Buglink: https://bugzilla.redhat.com/show_bug.cgi?id=2215192
> Buglink: https://bugzilla.redhat.com/show_bug.cgi?id=2214985
> Buglink: https://issues.redhat.com/browse/RHEL-17369
> Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
With the patch I can no longer see any do_qmp_dispatch_bh() calls run in
vCPU threads.
I also did a bit of smoke testing with some other QMP and QGA commands
and didn't find any obvious breakage, so:
Tested-by: Fiona Ebner <f.ebner@proxmox.com>
P.S.
Unfortunately, the patch does not solve the other issue I came across
back then [0] with snapshot_save_job_bh() being executed during a vCPU
thread's aio_poll(). See also [1].
I suppose this would need some other mechanism to solve or could it also
be scheduled to the iohandler AioContext? It's not directly related to
your patch of course, just mentioning it, because it's a similar theme.
[0]:
https://lore.kernel.org/qemu-devel/31757c45-695d-4408-468c-c2de560aff9c@proxmox.com/
[1]: https://gitlab.com/qemu-project/qemu/-/issues/2111
Best Regards,
Fiona
next prev parent reply other threads:[~2024-01-18 15:48 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-01-16 19:00 [PATCH 0/3] monitor: only run coroutine commands in qemu_aio_context Stefan Hajnoczi
2024-01-16 19:00 ` [PATCH 1/3] iotests: add filter_qmp_generated_node_ids() Stefan Hajnoczi
2024-01-17 16:13 ` Kevin Wolf
2024-01-16 19:00 ` [PATCH 2/3] iotests: port 141 to Python for reliable QMP testing Stefan Hajnoczi
2024-01-17 16:13 ` Kevin Wolf
2024-01-17 18:04 ` Kevin Wolf
2024-01-18 14:55 ` Stefan Hajnoczi
2024-01-18 15:36 ` Kevin Wolf
2024-01-16 19:00 ` [PATCH 3/3] monitor: only run coroutine commands in qemu_aio_context Stefan Hajnoczi
2024-01-17 18:10 ` Kevin Wolf
2024-01-18 15:47 ` Fiona Ebner [this message]
2024-02-03 9:01 ` Michael Tokarev
2024-02-03 11:30 ` Michael Tokarev
2024-02-13 20:19 ` Stefan Hajnoczi
2024-01-18 11:20 ` [PATCH 0/3] " Michael Tokarev
2024-01-29 11:38 ` Peter Maydell
2024-02-03 2:19 ` YangHang Liu
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=06e2bccc-0a5b-4b58-9c4e-7b369f5d3076@proxmox.com \
--to=f.ebner@proxmox.com \
--cc=armbru@redhat.com \
--cc=hreitz@redhat.com \
--cc=kwolf@redhat.com \
--cc=michael.roth@amd.com \
--cc=pbonzini@redhat.com \
--cc=qemu-block@nongnu.org \
--cc=qemu-devel@nongnu.org \
--cc=stefanha@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).