From: Peter Xu <peterx@redhat.com>
To: "Daniel P. Berrangé" <berrange@redhat.com>
Cc: Stefan Hajnoczi <stefanha@redhat.com>,
qemu-devel@nongnu.org, Stefan Hajnoczi <shajnocz@redhat.com>,
Paolo Bonzini <pbonzini@redhat.com>, Fam Zheng <famz@redhat.com>,
Juan Quintela <quintela@redhat.com>,
mdroth@linux.vnet.ibm.com, Eric Blake <eblake@redhat.com>,
Laurent Vivier <lvivier@redhat.com>,
Markus Armbruster <armbru@redhat.com>,
marcandre.lureau@redhat.com,
"Dr . David Alan Gilbert" <dgilbert@redhat.com>
Subject: Re: [Qemu-devel] [PATCH v7 09/23] monitor: allow using IO thread for parsing
Date: Fri, 23 Feb 2018 10:56:11 +0800 [thread overview]
Message-ID: <20180223025611.GK18962@xz-mi> (raw)
In-Reply-To: <20180222155047.GQ9323@redhat.com>
On Thu, Feb 22, 2018 at 03:50:47PM +0000, Daniel P. Berrangé wrote:
> On Thu, Feb 22, 2018 at 06:01:19PM +0800, Peter Xu wrote:
> > On Wed, Feb 21, 2018 at 04:00:07PM +0000, Stefan Hajnoczi wrote:
> > > On Wed, Jan 24, 2018 at 01:39:43PM +0800, Peter Xu wrote:
> > > > @@ -4034,12 +4044,29 @@ static void sortcmdlist(void)
> > > > qsort((void *)info_cmds, array_num, elem_size, compare_mon_cmd);
> > > > }
> > > >
> > > > +static GMainContext *monitor_io_context_get(void)
> > > > +{
> > > > + return iothread_get_g_main_context(mon_global.mon_iothread);
> > > > +}
> > > > +
> > > > +static AioContext *monitor_aio_context_get(void)
> > > > +{
> > > > + return iothread_get_aio_context(mon_global.mon_iothread);
> > > > +}
> > >
> > > Please follow the X_get_Y() naming convention instead of X_Y_get(). For
> > > example, see qemu_get_aio_context() and iothread_get_aio_context().
> >
> > Sure.
> >
> > >
> > > > @@ -4082,11 +4109,41 @@ void error_vprintf_unless_qmp(const char *fmt, va_list ap)
> > > > }
> > > > }
> > > >
> > > > +static void monitor_list_append(Monitor *mon)
> > > > +{
> > > > + qemu_mutex_lock(&monitor_lock);
> > > > + QTAILQ_INSERT_HEAD(&mon_list, mon, entry);
> > > > + qemu_mutex_unlock(&monitor_lock);
> > > > +}
> > > > +
> > > > +static void monitor_qmp_setup_handlers(void *data)
> > >
> > > BH functions are usually declared like this:
> > >
> > > static void X_bh(void *opaque)
> > >
> > > This way it's immediately clear that this function is invoked as a BH.
> > >
> > > I suggest renaming the function to monitor_qmp_setup_handlers_bh().
> > > Using 'opaque' instead of 'data' is common, too.
> >
> > Sure.
> >
> > >
> > > > @@ -4099,24 +4156,55 @@ void monitor_init(Chardev *chr, int flags)
> > > > }
> > > >
> > > > if (monitor_is_qmp(mon)) {
> > > > - qemu_chr_fe_set_handlers(&mon->chr, monitor_can_read, monitor_qmp_read,
> > > > - monitor_qmp_event, NULL, mon, NULL, true);
> > > > qemu_chr_fe_set_echo(&mon->chr, true);
> > > > json_message_parser_init(&mon->qmp.parser, handle_qmp_command);
> > > > + if (mon->use_io_thr) {
> > > > + /*
> > > > + * It's possible that we already have an IOWatchPoll
> > > > + * registered for the Chardev during chardev_init_func().
> > >
> > > When does this happen?
> > >
> > > This seems like a hack that breaks when certain -chardev options are
> > > used. For example, what happens if the chardev is a TCP connection with
> > > reconnect=5. In that case the socket will be connecting asynchronously
> > > and we cannot just remove the fd watch.
> > >
> > > How does this interact with TCP listen chardevs? It looks like the
> > > listener socket uses the main loop (see tcp_chr_disconnect()).
> > >
> > > I'm worried that the chardev layer isn't thread-safe and you haven't
> > > added anything to protect it or at least refuse to run in unsafe
> > > conditions.
> >
> > Indeed, I did some more reading and noticed that the TCP typed chardev
> > is really special.
> >
> > Firstly there can be the QIO thread that handles sync connecting when
> > "reconnect" is setup (I don't really understand why we only need the
> > threads when reconnect != 0, but anyway, I'll just assume we need the
> > threads). It's done in qmp_chardev_open_socket().
> >
> > Secondly, TCP can support TLS or TELNET (tcp_chr_new_client() handles
> > the main logic of it), so there can be actually more than one GSource
> > created for a single TCP chardev. Meanwhile, the
> > chr_update_read_handler() calls never handles the re-setup of those
> > special GSources (TLS/TELNET), only the common GSource of TCP stream
> > read/write.
> >
> > And the whole TCP channel is based on QIO stuff, which means I need to
> > add non-default context support to QIO stuff too... That's mostly
> > about qio_channel_add_watch(). I may need to pass in context
> > information, and switch to GSource for that function instead of the
> > old tags, just like what I did to chardev in general.
>
> Rather than changing qio_channel_add_watch() which affects all callers,
> just add a qio_channel_add_watch_full() variant which includes GMainContext
> as an extra arg
Yeh, will do. Thanks,
--
Peter Xu
next prev parent reply other threads:[~2018-02-23 2:58 UTC|newest]
Thread overview: 50+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-01-24 5:39 [Qemu-devel] [PATCH v7 00/23] QMP: out-of-band (OOB) execution support Peter Xu
2018-01-24 5:39 ` [Qemu-devel] [PATCH v7 01/23] docs: update QMP documents for OOB commands Peter Xu
2018-02-09 14:10 ` Eric Blake
2018-02-11 5:34 ` Peter Xu
2018-01-24 5:39 ` [Qemu-devel] [PATCH v7 02/23] qobject: introduce qstring_get_try_str() Peter Xu
2018-01-24 5:39 ` [Qemu-devel] [PATCH v7 03/23] qobject: introduce qobject_get_try_str() Peter Xu
2018-01-24 5:39 ` [Qemu-devel] [PATCH v7 04/23] qobject: let object_property_get_str() use new API Peter Xu
2018-01-24 5:39 ` [Qemu-devel] [PATCH v7 05/23] monitor: move skip_flush into monitor_data_init Peter Xu
2018-01-24 5:39 ` [Qemu-devel] [PATCH v7 06/23] monitor: move the cur_mon hack deeper for QMP Peter Xu
2018-01-24 5:39 ` [Qemu-devel] [PATCH v7 07/23] monitor: unify global init Peter Xu
2018-01-24 5:39 ` [Qemu-devel] [PATCH v7 08/23] monitor: let mon_list be tail queue Peter Xu
2018-01-24 5:39 ` [Qemu-devel] [PATCH v7 09/23] monitor: allow using IO thread for parsing Peter Xu
2018-02-21 16:00 ` Stefan Hajnoczi
2018-02-22 10:01 ` Peter Xu
2018-02-22 15:41 ` Stefan Hajnoczi
2018-02-22 15:50 ` Daniel P. Berrangé
2018-02-23 2:56 ` Peter Xu [this message]
2018-01-24 5:39 ` [Qemu-devel] [PATCH v7 10/23] qmp: introduce QMPCapability Peter Xu
2018-02-21 16:17 ` Stefan Hajnoczi
2018-02-22 10:42 ` Peter Xu
2018-01-24 5:39 ` [Qemu-devel] [PATCH v7 11/23] monitor: introduce monitor_qmp_respond() Peter Xu
2018-01-24 5:39 ` [Qemu-devel] [PATCH v7 12/23] monitor: let suspend_cnt be thread safe Peter Xu
2018-02-21 16:44 ` Stefan Hajnoczi
2018-02-21 16:45 ` Stefan Hajnoczi
2018-02-21 16:45 ` Stefan Hajnoczi
2018-01-24 5:39 ` [Qemu-devel] [PATCH v7 13/23] monitor: let suspend/resume work even with QMPs Peter Xu
2018-02-21 16:50 ` Stefan Hajnoczi
2018-02-22 10:49 ` Peter Xu
2018-01-24 5:39 ` [Qemu-devel] [PATCH v7 14/23] monitor: separate QMP parser and dispatcher Peter Xu
2018-02-21 17:17 ` Stefan Hajnoczi
2018-01-24 5:39 ` [Qemu-devel] [PATCH v7 15/23] qmp: add new event "command-dropped" Peter Xu
2018-02-21 17:19 ` Stefan Hajnoczi
2018-01-24 5:39 ` [Qemu-devel] [PATCH v7 16/23] monitor: send event when command queue full Peter Xu
2018-02-21 17:23 ` Stefan Hajnoczi
2018-01-24 5:39 ` [Qemu-devel] [PATCH v7 17/23] qapi: introduce new cmd option "allow-oob" Peter Xu
2018-03-08 10:04 ` Igor Mammedov
2018-03-08 11:43 ` Peter Xu
2018-03-08 11:51 ` Peter Xu
2018-01-24 5:39 ` [Qemu-devel] [PATCH v7 18/23] qmp: support out-of-band (oob) execution Peter Xu
2018-02-21 17:34 ` Stefan Hajnoczi
2018-01-24 5:39 ` [Qemu-devel] [PATCH v7 19/23] qmp: isolate responses into io thread Peter Xu
2018-02-21 17:44 ` Stefan Hajnoczi
2018-01-24 5:39 ` [Qemu-devel] [PATCH v7 20/23] monitor: enable IO thread for (qmp & !mux) typed Peter Xu
2018-01-24 5:39 ` [Qemu-devel] [PATCH v7 21/23] qmp: add command "x-oob-test" Peter Xu
2018-01-24 5:39 ` [Qemu-devel] [PATCH v7 22/23] tests: qmp-test: verify command batching Peter Xu
2018-01-24 5:39 ` [Qemu-devel] [PATCH v7 23/23] tests: qmp-test: add oob test Peter Xu
2018-01-25 2:35 ` [Qemu-devel] [PATCH v7 00/23] QMP: out-of-band (OOB) execution support Peter Xu
2018-01-25 10:01 ` Dr. David Alan Gilbert
2018-02-08 6:44 ` Peter Xu
2018-02-21 17:45 ` Stefan Hajnoczi
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=20180223025611.GK18962@xz-mi \
--to=peterx@redhat.com \
--cc=armbru@redhat.com \
--cc=berrange@redhat.com \
--cc=dgilbert@redhat.com \
--cc=eblake@redhat.com \
--cc=famz@redhat.com \
--cc=lvivier@redhat.com \
--cc=marcandre.lureau@redhat.com \
--cc=mdroth@linux.vnet.ibm.com \
--cc=pbonzini@redhat.com \
--cc=qemu-devel@nongnu.org \
--cc=quintela@redhat.com \
--cc=shajnocz@redhat.com \
--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).