From: Li Zhang <zhlcindy@gmail.com>
To: "Marc-André Lureau" <marcandre.lureau@gmail.com>
Cc: Li Zhang <li.zhang@cloud.ionos.com>,
Markus Armbruster <armbru@redhat.com>,
Pankaj Gupta <pankaj.gupta@ionos.com>,
QEMU <qemu-devel@nongnu.org>
Subject: Re: [PATCHv2 1/1] Support monitor chardev hotswap with QMP
Date: Fri, 16 Apr 2021 17:46:51 +0200 [thread overview]
Message-ID: <CAD8of+oyjd6mSvbOUBAB1+o50CK2Syw7Rn1pV7M9cPRf3xYkPQ@mail.gmail.com> (raw)
In-Reply-To: <CAJ+F1CLW1rCV1rnxxhtAMEoVttA+nbWetbQkd7C3G16NTR2NRw@mail.gmail.com>
Hi Marc-André,
On Fri, Apr 16, 2021 at 5:28 PM Marc-André Lureau
<marcandre.lureau@gmail.com> wrote:
>
> Hi
>
> On Fri, Apr 16, 2021 at 6:59 PM Marc-André Lureau <marcandre.lureau@gmail.com> wrote:
>>
>> Hi
>>
>> On Fri, Apr 16, 2021 at 6:51 PM Markus Armbruster <armbru@redhat.com> wrote:
>>>
>>> Marc-André, I'd like your opinion for this one, in particular the use of
>>> g_source_remove().
>>
>>
>> My opinion isn't really worth much, my review would have a bit more value.
>>
>> GSource has indeed some peculiar lifetime management, that I got wrong in the past. So I would be extra careful.
>>
>> But before spending time on review, I would also clarify the motivation and ask for testing.
>>
>> Markus, hot-adding/removing monitors isn't supported?
>>
>
> I realize you answered my question below. That's surprising me. Wouldn't it make more sense to support it rather than having a pre-opened null-based monitor that can have its chardev swapped?
It's the best way to support hot-add/remove monitor devices. But we
would like to use it as soon as possible, so I use hotswap currently.
If possible, we can consider implementing hot-add/remove in the future.
>
>>>
>>>
>>> Li Zhang <zhlcindy@gmail.com> writes:
>>>
>>> > For some scenarios, it needs to hot-add a monitor device.
>>> > But QEMU doesn't support hotplug yet. It also works by adding
>>> > a monitor with null backend by default and then change its
>>> > backend to socket by QMP command "chardev-change".
>>> >
>>> > So this patch is to support monitor chardev hotswap with QMP.
>>> >
>>> > Signed-off-by: Li Zhang <li.zhang@cloud.ionos.com>
>>> > Reviewed-by: Pankaj Gupta <pankaj.gupta@ionos.com>
>>>
>>> Your commit message starts with a brief description of the problem.
>>> Appreciated! But I think it could be a bit clearer. What about this:
>>>
>>> qmp: Support chardev-change
>>>
>>> For some scenarios, we'd like to hot-add a monitor device. But QEMU
>>> doesn't support that, yet. It does support hot-swapping character
>>> backends with QMP command chardev-change. This lets us pre-add a
>>> monitor with a null character backend, then chardev-change to a
>>> socket backend. Except the chardev-change fails with "Chardev user
>>> does not support chardev hotswap" because monitors don't provide the
>>> required callback. Implement it for QMP monitors.
>>>
>>> > ---
>>> > v1 -> v2:
>>> > - Change mutex lock mon_lock section
>>> > - Fix indentation problems
>>> >
>>> > monitor/monitor-internal.h | 3 +++
>>> > monitor/monitor.c | 2 +-
>>> > monitor/qmp.c | 43 +++++++++++++++++++++++++++++++++++---
>>> > 3 files changed, 44 insertions(+), 4 deletions(-)
>>> >
>>> > diff --git a/monitor/monitor-internal.h b/monitor/monitor-internal.h
>>> > index 9c3a09cb01..1b80c74883 100644
>>> > --- a/monitor/monitor-internal.h
>>> > +++ b/monitor/monitor-internal.h
>>> > @@ -183,4 +183,7 @@ void help_cmd(Monitor *mon, const char *name);
>>> > void handle_hmp_command(MonitorHMP *mon, const char *cmdline);
>>> > int hmp_compare_cmd(const char *name, const char *list);
>>> >
>>> > +gboolean monitor_unblocked(GIOChannel *chan, GIOCondition cond,
>>> > + void *opaque);
>>> > +
>>> > #endif
>>> > diff --git a/monitor/monitor.c b/monitor/monitor.c
>>> > index 636bcc81c5..16a3620d02 100644
>>> > --- a/monitor/monitor.c
>>> > +++ b/monitor/monitor.c
>>> > @@ -157,7 +157,7 @@ static inline bool monitor_is_hmp_non_interactive(const Monitor *mon)
>>> >
>>> > static void monitor_flush_locked(Monitor *mon);
>>> >
>>> > -static gboolean monitor_unblocked(GIOChannel *chan, GIOCondition cond,
>>> > +gboolean monitor_unblocked(GIOChannel *chan, GIOCondition cond,
>>> > void *opaque)
>>> > {
>>> > Monitor *mon = opaque;
>>> > diff --git a/monitor/qmp.c b/monitor/qmp.c
>>> > index 2b0308f933..5fa65401ae 100644
>>> > --- a/monitor/qmp.c
>>> > +++ b/monitor/qmp.c
>>> > @@ -44,6 +44,7 @@ struct QMPRequest {
>>> > Error *err;
>>> > };
>>> > typedef struct QMPRequest QMPRequest;
>>> > +static void monitor_qmp_set_handlers_bh(void *opaque);
>>> >
>>> > QmpCommandList qmp_commands, qmp_cap_negotiation_commands;
>>> >
>>> > @@ -477,7 +478,36 @@ void monitor_data_destroy_qmp(MonitorQMP *mon)
>>> > g_queue_free(mon->qmp_requests);
>>> > }
>>> >
>>> > -static void monitor_qmp_setup_handlers_bh(void *opaque)
>>> > +static int monitor_qmp_change (void *opaque)
>>> > +{
>>> > + MonitorQMP *mon = opaque;
>>> > +
>>> > + mon->common.use_io_thread = qemu_chr_has_feature(mon->common.chr.chr,
>>> > + QEMU_CHAR_FEATURE_GCONTEXT);
>>> > +
>>> > + if (mon->common.use_io_thread) {
>>> > + aio_bh_schedule_oneshot(iothread_get_aio_context(mon_iothread),
>>> > + monitor_qmp_set_handlers_bh, mon);
>>> > + } else {
>>> > + qemu_chr_fe_set_handlers(&mon->common.chr, monitor_can_read,
>>> > + monitor_qmp_read, monitor_qmp_event,
>>> > + monitor_qmp_change, &mon->common, NULL, true);
>>> > + }
>>> > +
>>> > + qemu_mutex_lock(&mon->common.mon_lock);
>>> > + if (mon->common.out_watch) {
>>> > + g_source_remove(mon->common.out_watch);
>>> > + mon->common.out_watch = qemu_chr_fe_add_watch(&mon->common.chr,
>>> > + G_IO_OUT | G_IO_HUP,
>>> > + monitor_unblocked,
>>> > + &mon->common);
>>>
>>> Visually align the arguments:
>>>
>>> mon->common.out_watch = qemu_chr_fe_add_watch(&mon->common.chr,
>>> G_IO_OUT | G_IO_HUP,
>>> monitor_unblocked,
>>> &mon->common);
>>>
>>> You may reduce argument indentation some to gain extra space, but keep
>>> the arguments more indented than the function:
>>>
>>> mon->common.out_watch = qemu_chr_fe_add_watch(&mon->common.chr,
>>> G_IO_OUT | G_IO_HUP,
>>> monitor_unblocked, &mon->common);
>>>
>>> Do this only when you actually use the extra space for readability.
>>>
>>> > + }
>>> > + qemu_mutex_unlock(&mon->common.mon_lock);
>>> > +
>>> > + return 0;
>>> > +}
>>>
>>> As I wrote in my review of v1, this function copies from
>>> monitor_data_init(), monitor_init_qmp(), and monitor_flush_locked().
>>> Feels like a refactoring would be in order. Doing it on top might be
>>> easier.
>>>
>>> > +
>>> > +static void monitor_qmp_set_handlers_bh(void *opaque)
>>> > {
>>> > MonitorQMP *mon = opaque;
>>> > GMainContext *context;
>>> > @@ -487,7 +517,14 @@ static void monitor_qmp_setup_handlers_bh(void *opaque)
>>> > assert(context);
>>> > qemu_chr_fe_set_handlers(&mon->common.chr, monitor_can_read,
>>> > monitor_qmp_read, monitor_qmp_event,
>>> > - NULL, &mon->common, context, true);
>>> > + monitor_qmp_change, &mon->common, context, true);
>>> > +
>>> > +}
>>> > +
>>> > +static void monitor_qmp_setup_handlers_bh(void *opaque)
>>> > +{
>>> > + MonitorQMP *mon = opaque;
>>> > + monitor_qmp_set_handlers_bh(mon);
>>> > monitor_list_append(&mon->common);
>>> > }
>>> >
>>> > @@ -528,7 +565,7 @@ void monitor_init_qmp(Chardev *chr, bool pretty, Error **errp)
>>> > } else {
>>> > qemu_chr_fe_set_handlers(&mon->common.chr, monitor_can_read,
>>> > monitor_qmp_read, monitor_qmp_event,
>>> > - NULL, &mon->common, NULL, true);
>>> > + monitor_qmp_change, &mon->common, NULL, true);
>>> > monitor_list_append(&mon->common);
>>> > }
>>> > }
>>>
>>>
>>
>>
>> --
>> Marc-André Lureau
>
>
>
> --
> Marc-André Lureau
--
Best Regards
-Li
next prev parent reply other threads:[~2021-04-16 15:53 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-04-13 21:34 [PATCHv2 1/1] Support monitor chardev hotswap with QMP Li Zhang
2021-04-15 15:07 ` Li Zhang
2021-04-16 14:50 ` Markus Armbruster
2021-04-16 14:59 ` Marc-André Lureau
2021-04-16 15:28 ` Marc-André Lureau
2021-04-16 15:46 ` Li Zhang [this message]
2021-04-17 8:02 ` Markus Armbruster
2021-04-19 11:56 ` Li Zhang
2021-05-04 6:29 ` Pankaj Gupta
2021-05-04 8:38 ` Daniel P. Berrangé
2021-04-16 15:20 ` Li Zhang
2021-04-17 8:05 ` Markus Armbruster
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=CAD8of+oyjd6mSvbOUBAB1+o50CK2Syw7Rn1pV7M9cPRf3xYkPQ@mail.gmail.com \
--to=zhlcindy@gmail.com \
--cc=armbru@redhat.com \
--cc=li.zhang@cloud.ionos.com \
--cc=marcandre.lureau@gmail.com \
--cc=pankaj.gupta@ionos.com \
--cc=qemu-devel@nongnu.org \
/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).