[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [RFC 0/3] qmp: make qmp_device_add() a coroutine
From: |
Paolo Bonzini |
Subject: |
Re: [RFC 0/3] qmp: make qmp_device_add() a coroutine |
Date: |
Thu, 7 Sep 2023 16:25:19 +0200 |
On Thu, Sep 7, 2023 at 4:00 PM Stefan Hajnoczi <stefanha@redhat.com> wrote:
> While I agree that the issue would not happen if monitor commands only
> ran in the iohandler AioContext, I don't think we can change that.
> When Kevin implemented coroutine commands in commit 9ce44e2ce267 ("qmp:
> Move dispatcher to a coroutine"), he used qemu_get_aio_context()
> deliberately so that AIO_WAIT_WHILE() can make progress.
Ah, you are referring to
+ /*
+ * Move the coroutine from iohandler_ctx to qemu_aio_context for
+ * executing the command handler so that it can make progress if it
+ * involves an AIO_WAIT_WHILE().
+ */
+ aio_co_schedule(qemu_get_aio_context(), qmp_dispatcher_co);
+ qemu_coroutine_yield();
> I'm not clear on the exact scenario though, because coroutines shouldn't
> call AIO_WAIT_WHILE().
I think he meant "so that an AIO_WAIT_WHILE() invoked through a bottom
half will make progress on the coroutine as well".
However I am not sure the comment applies here, because
do_qmp_dispatch_bh() only applies to non-coroutine commands; that
commit allowed monitor commands to run in vCPU threads when they
previously weren't.
Thinking more about it, I don't like that the
if (!!(cmd->options & QCO_COROUTINE) == qemu_in_coroutine()) {
}
check is in qmp_dispatch() rather than monitor_qmp_dispatch().
Any caller of qmp_dispatch() knows if it is in a coroutine or not.
qemu-ga uses neither a coroutine dispatcher nor coroutine commands.
QEMU uses non-coroutine dispatch for out-of-band commands (and we can
forbid coroutine + allow-oob at the same time), and coroutine dispatch
for the others.
So, moving out of coroutine context (through a bottom half) should be
done by monitor_qmp_dispatch(), and likewise moving temporarily out of
the iohandler context in the case of coroutine commands. In the case
of !req_obj->req you don't need to do either of those. qmp_dispatch()
can still assert that the coroutine-ness of the command matches the
context in which qmp_dispatch() is called.
Once this is done, I think moving out of coroutine context can use a
BH that runs in the iohandler context.
Paolo
- Re: [RFC 1/3] hmp: avoid the nested event loop in handle_hmp_command(), (continued)
[RFC 3/3] qmp: make qmp_device_add() a coroutine, Stefan Hajnoczi, 2023/09/06
[RFC 2/3] rcu: add drain_call_rcu_co() API, Stefan Hajnoczi, 2023/09/06
Re: [RFC 0/3] qmp: make qmp_device_add() a coroutine, Paolo Bonzini, 2023/09/07