From: Peter Xu <peterx@redhat.com>
To: qemu-devel@nongnu.org
Cc: Stefan Hajnoczi <shajnocz@redhat.com>,
"Daniel P . Berrange" <berrange@redhat.com>,
Paolo Bonzini <pbonzini@redhat.com>, Fam Zheng <famz@redhat.com>,
Juan Quintela <quintela@redhat.com>,
mdroth@linux.vnet.ibm.com, peterx@redhat.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: [Qemu-devel] [RFC v6 22/27] qmp: isolate responses into io thread
Date: Tue, 19 Dec 2017 16:45:52 +0800 [thread overview]
Message-ID: <20171219084557.9801-23-peterx@redhat.com> (raw)
In-Reply-To: <20171219084557.9801-1-peterx@redhat.com>
For those monitors who has enabled IO thread, we'll offload the
responding procedure into IO thread. The main reason is that chardev is
not thread safe, and we need to do all the read/write IOs in the same
thread. For use_io_thr=true monitors, that thread is the IO thread.
We do this isolation in similar pattern as what we have done to the
request queue: we first create one response queue for each monitor, then
instead of reply directly in main thread, we queue the responses and
kick the IO thread to do the rest of the job for us.
A funny thing after doing this is that, when the QMP clients send "quit"
to QEMU, it's possible that we close the IOThread even earlier than
replying to that "quit". So another thing we need to do before cleaning
up the monitors is that we need to flush the response queue (we don't
need to do that for command queue; after all we are quitting) to make
sure replies for handled commands are always flushed back to clients.
Signed-off-by: Peter Xu <peterx@redhat.com>
---
monitor.c | 100 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++-
1 file changed, 99 insertions(+), 1 deletion(-)
diff --git a/monitor.c b/monitor.c
index 505db439d8..0c6403bc65 100644
--- a/monitor.c
+++ b/monitor.c
@@ -174,6 +174,8 @@ typedef struct {
QemuMutex qmp_queue_lock;
/* Input queue that holds all the parsed QMP requests */
GQueue *qmp_requests;
+ /* Output queue contains all the QMP responses in order */
+ GQueue *qmp_responses;
} MonitorQMP;
/*
@@ -222,6 +224,8 @@ static struct {
IOThread *mon_iothread;
/* Bottom half to dispatch the requests received from IO thread */
QEMUBH *qmp_dispatcher_bh;
+ /* Bottom half to deliver the responses back to clients */
+ QEMUBH *qmp_respond_bh;
} mon_global;
/* QMP checker flags */
@@ -396,7 +400,8 @@ int monitor_fprintf(FILE *stream, const char *fmt, ...)
return 0;
}
-static void monitor_json_emitter(Monitor *mon, const QObject *data)
+static void monitor_json_emitter_raw(Monitor *mon,
+ QObject *data)
{
QString *json;
@@ -410,6 +415,71 @@ static void monitor_json_emitter(Monitor *mon, const QObject *data)
QDECREF(json);
}
+static void monitor_json_emitter(Monitor *mon, QObject *data)
+{
+ if (mon->use_io_thr) {
+ /*
+ * If using IO thread, we need to queue the item so that IO
+ * thread will do the rest for us. Take refcount so that
+ * caller won't free the data (which will be finally freed in
+ * responder thread).
+ */
+ qobject_incref(data);
+ qemu_mutex_lock(&mon->qmp.qmp_queue_lock);
+ g_queue_push_tail(mon->qmp.qmp_responses, (void *)data);
+ qemu_mutex_unlock(&mon->qmp.qmp_queue_lock);
+ qemu_bh_schedule(mon_global.qmp_respond_bh);
+ } else {
+ /*
+ * If not using monitor IO thread, then we are in main thread.
+ * Do the emission right away.
+ */
+ monitor_json_emitter_raw(mon, data);
+ }
+}
+
+struct QMPResponse {
+ Monitor *mon;
+ QObject *data;
+};
+typedef struct QMPResponse QMPResponse;
+
+/*
+ * Return one QMPResponse. The response is only valid if
+ * response.data is not NULL.
+ */
+static QMPResponse monitor_qmp_response_pop_one(void)
+{
+ Monitor *mon;
+ QObject *data = NULL;
+
+ qemu_mutex_lock(&monitor_lock);
+ QTAILQ_FOREACH(mon, &mon_list, entry) {
+ qemu_mutex_lock(&mon->qmp.qmp_queue_lock);
+ data = g_queue_pop_head(mon->qmp.qmp_responses);
+ qemu_mutex_unlock(&mon->qmp.qmp_queue_lock);
+ if (data) {
+ break;
+ }
+ }
+ qemu_mutex_unlock(&monitor_lock);
+ return (QMPResponse) { .mon = mon, .data = data };
+}
+
+static void monitor_qmp_bh_responder(void *opaque)
+{
+ QMPResponse response;
+
+ while (true) {
+ response = monitor_qmp_response_pop_one();
+ if (!response.data) {
+ break;
+ }
+ monitor_json_emitter_raw(response.mon, response.data);
+ qobject_decref(response.data);
+ }
+}
+
static MonitorQAPIEventConf monitor_qapi_event_conf[QAPI_EVENT__MAX] = {
/* Limit guest-triggerable events to 1 per second */
[QAPI_EVENT_RTC_CHANGE] = { 1000 * SCALE_MS },
@@ -596,6 +666,7 @@ static void monitor_data_init(Monitor *mon, bool skip_flush,
mon->skip_flush = skip_flush;
mon->use_io_thr = use_io_thr;
mon->qmp.qmp_requests = g_queue_new();
+ mon->qmp.qmp_responses = g_queue_new();
}
static void monitor_data_destroy(Monitor *mon)
@@ -610,6 +681,7 @@ static void monitor_data_destroy(Monitor *mon)
qemu_mutex_destroy(&mon->out_lock);
qemu_mutex_destroy(&mon->qmp.qmp_queue_lock);
g_queue_free(mon->qmp.qmp_requests);
+ g_queue_free(mon->qmp.qmp_responses);
}
char *qmp_human_monitor_command(const char *command_line, bool has_cpu_index,
@@ -4368,6 +4440,11 @@ 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);
+}
+
static void monitor_iothread_init(void)
{
mon_global.mon_iothread = iothread_create("mon_iothread",
@@ -4381,6 +4458,15 @@ static void monitor_iothread_init(void)
mon_global.qmp_dispatcher_bh = aio_bh_new(qemu_get_aio_context(),
monitor_qmp_bh_dispatcher,
NULL);
+
+ /*
+ * Unlike the dispatcher BH, this must be run on the monitor IO
+ * thread, so that monitors that are using IO thread will make
+ * sure read/write operations are all done on the IO thread.
+ */
+ mon_global.qmp_respond_bh = aio_bh_new(monitor_aio_context_get(),
+ monitor_qmp_bh_responder,
+ NULL);
}
void monitor_init_globals(void)
@@ -4495,9 +4581,19 @@ void monitor_cleanup(void)
*/
iothread_stop(mon_global.mon_iothread);
+ /*
+ * After we have IOThread to send responses, it's possible that
+ * when we stop the IOThread there are still replies queued in the
+ * responder queue. Flush all of them. Note that even after this
+ * flush it's still possible that out buffer is not flushed.
+ * It'll be done in below monitor_flush() as the last resort.
+ */
+ monitor_qmp_bh_responder(NULL);
+
qemu_mutex_lock(&monitor_lock);
QTAILQ_FOREACH_SAFE(mon, &mon_list, entry, next) {
QTAILQ_REMOVE(&mon_list, mon, entry);
+ monitor_flush(mon);
monitor_data_destroy(mon);
g_free(mon);
}
@@ -4506,6 +4602,8 @@ void monitor_cleanup(void)
/* QEMUBHs needs to be deleted before destroying the IOThread. */
qemu_bh_delete(mon_global.qmp_dispatcher_bh);
mon_global.qmp_dispatcher_bh = NULL;
+ qemu_bh_delete(mon_global.qmp_respond_bh);
+ mon_global.qmp_respond_bh = NULL;
iothread_destroy(mon_global.mon_iothread);
mon_global.mon_iothread = NULL;
--
2.14.3
next prev parent reply other threads:[~2017-12-19 8:50 UTC|newest]
Thread overview: 114+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-12-19 8:45 [Qemu-devel] [RFC v6 00/27] QMP: out-of-band (OOB) execution support Peter Xu
2017-12-19 8:45 ` [Qemu-devel] [RFC v6 01/27] chardev: use backend chr context when watch for fe Peter Xu
2017-12-20 16:40 ` Stefan Hajnoczi
2017-12-25 2:58 ` Peter Xu
2017-12-20 16:40 ` Stefan Hajnoczi
2017-12-19 8:45 ` [Qemu-devel] [RFC v6 02/27] qobject: introduce qstring_get_try_str() Peter Xu
2018-01-09 22:47 ` Eric Blake
2017-12-19 8:45 ` [Qemu-devel] [RFC v6 03/27] qobject: introduce qobject_get_try_str() Peter Xu
2018-01-09 22:50 ` Eric Blake
2018-01-10 7:52 ` Peter Xu
2017-12-19 8:45 ` [Qemu-devel] [RFC v6 04/27] qobject: let object_property_get_str() use new API Peter Xu
2018-01-09 22:53 ` Eric Blake
2018-01-10 7:57 ` Peter Xu
2018-01-10 12:59 ` Eric Blake
2018-01-11 8:17 ` Peter Xu
2017-12-19 8:45 ` [Qemu-devel] [RFC v6 05/27] monitor: move skip_flush into monitor_data_init Peter Xu
2017-12-19 8:45 ` [Qemu-devel] [RFC v6 06/27] monitor: move the cur_mon hack deeper for QMP Peter Xu
2017-12-20 16:42 ` Stefan Hajnoczi
2018-01-09 22:57 ` Eric Blake
2017-12-19 8:45 ` [Qemu-devel] [RFC v6 07/27] monitor: unify global init Peter Xu
2017-12-20 16:42 ` Stefan Hajnoczi
2018-01-09 23:13 ` Eric Blake
2018-01-10 8:26 ` Peter Xu
2018-01-10 12:54 ` Eric Blake
2018-01-11 8:18 ` Peter Xu
2017-12-19 8:45 ` [Qemu-devel] [RFC v6 08/27] monitor: let mon_list be tail queue Peter Xu
2017-12-19 8:45 ` [Qemu-devel] [RFC v6 09/27] monitor: create monitor dedicate iothread Peter Xu
2017-12-21 6:18 ` Fam Zheng
2018-01-05 16:23 ` Stefan Hajnoczi
2018-01-09 23:31 ` Eric Blake
2018-01-10 8:34 ` Peter Xu
2017-12-19 8:45 ` [Qemu-devel] [RFC v6 10/27] monitor: allow to use IO thread for parsing Peter Xu
2017-12-21 9:34 ` Fam Zheng
2018-01-05 17:22 ` Stefan Hajnoczi
2018-01-12 3:22 ` Peter Xu
2018-08-23 10:55 ` Marc-André Lureau
2018-01-09 23:37 ` Eric Blake
2018-01-12 3:23 ` Peter Xu
2017-12-19 8:45 ` [Qemu-devel] [RFC v6 11/27] qmp: introduce QMPCapability Peter Xu
2017-12-21 9:56 ` Fam Zheng
2017-12-25 3:16 ` Peter Xu
2018-01-08 16:23 ` Stefan Hajnoczi
2018-01-11 23:07 ` Eric Blake
2018-01-12 4:28 ` Peter Xu
2018-01-12 14:10 ` Eric Blake
2017-12-19 8:45 ` [Qemu-devel] [RFC v6 12/27] qmp: negotiate QMP capabilities Peter Xu
2017-12-21 10:01 ` Fam Zheng
2017-12-25 3:18 ` Peter Xu
2018-01-08 16:23 ` Stefan Hajnoczi
2018-01-12 20:57 ` Eric Blake
2018-01-22 7:29 ` Peter Xu
2017-12-19 8:45 ` [Qemu-devel] [RFC v6 13/27] monitor: introduce monitor_qmp_respond() Peter Xu
2018-01-08 16:25 ` Stefan Hajnoczi
2017-12-19 8:45 ` [Qemu-devel] [RFC v6 14/27] monitor: let suspend_cnt be thread safe Peter Xu
2018-01-12 21:48 ` Eric Blake
2018-01-22 7:43 ` Peter Xu
2017-12-19 8:45 ` [Qemu-devel] [RFC v6 15/27] monitor: let suspend/resume work even with QMPs Peter Xu
2017-12-21 11:27 ` Fam Zheng
2017-12-25 3:26 ` Peter Xu
2018-01-08 16:49 ` Stefan Hajnoczi
2018-01-12 4:51 ` Peter Xu
2018-01-12 14:28 ` Stefan Hajnoczi
2018-01-22 7:56 ` Peter Xu
2017-12-19 8:45 ` [Qemu-devel] [RFC v6 16/27] monitor: separate QMP parser and dispatcher Peter Xu
2017-12-21 11:40 ` Fam Zheng
2017-12-25 5:14 ` Peter Xu
2018-01-08 17:09 ` Stefan Hajnoczi
2018-01-12 6:05 ` Peter Xu
2018-01-12 14:22 ` Stefan Hajnoczi
2017-12-19 8:45 ` [Qemu-devel] [RFC v6 17/27] qmp: add new event "command-dropped" Peter Xu
2017-12-21 11:29 ` Fam Zheng
2018-01-09 13:20 ` Stefan Hajnoczi
2018-01-12 6:09 ` Peter Xu
2017-12-19 8:45 ` [Qemu-devel] [RFC v6 18/27] monitor: send event when command queue full Peter Xu
2017-12-21 11:42 ` Fam Zheng
2017-12-25 5:18 ` Peter Xu
2017-12-25 5:55 ` Fam Zheng
2017-12-25 6:18 ` Peter Xu
2017-12-25 7:13 ` Fam Zheng
2017-12-25 7:22 ` Peter Xu
2018-01-09 13:30 ` Stefan Hajnoczi
2018-01-09 13:42 ` Stefan Hajnoczi
2018-01-12 4:59 ` Peter Xu
2017-12-19 8:45 ` [Qemu-devel] [RFC v6 19/27] qapi: introduce new cmd option "allow-oob" Peter Xu
2017-12-21 11:45 ` Fam Zheng
2017-12-19 8:45 ` [Qemu-devel] [RFC v6 20/27] qmp: export qmp_dispatch_check_obj and allow "id" Peter Xu
2017-12-21 11:46 ` Fam Zheng
2018-01-09 13:45 ` Stefan Hajnoczi
2018-01-12 6:16 ` Peter Xu
2018-01-12 14:20 ` Stefan Hajnoczi
2018-01-22 8:42 ` Peter Xu
2017-12-19 8:45 ` [Qemu-devel] [RFC v6 21/27] qmp: support out-of-band (oob) execution Peter Xu
2017-12-21 11:54 ` Fam Zheng
2018-01-09 14:08 ` Stefan Hajnoczi
2018-01-12 6:23 ` Peter Xu
2018-01-12 14:18 ` Stefan Hajnoczi
2017-12-19 8:45 ` Peter Xu [this message]
2017-12-21 12:57 ` [Qemu-devel] [RFC v6 22/27] qmp: isolate responses into io thread Fam Zheng
2017-12-25 5:20 ` Peter Xu
2018-01-09 14:24 ` Stefan Hajnoczi
2018-01-12 6:44 ` Peter Xu
2018-01-12 14:16 ` Stefan Hajnoczi
2017-12-19 8:45 ` [Qemu-devel] [RFC v6 23/27] monitor: enable IO thread for (qmp & !mux) typed Peter Xu
2017-12-21 12:57 ` Fam Zheng
2018-01-09 14:24 ` Stefan Hajnoczi
2017-12-19 8:45 ` [Qemu-devel] [RFC v6 24/27] qmp: add command "x-oob-test" Peter Xu
2017-12-21 12:58 ` Fam Zheng
2017-12-19 8:45 ` [Qemu-devel] [RFC v6 25/27] docs: update QMP documents for OOB commands Peter Xu
2018-01-09 14:52 ` Stefan Hajnoczi
2018-01-12 6:54 ` Peter Xu
2017-12-19 8:45 ` [Qemu-devel] [RFC v6 26/27] tests: qmp-test: verify command batching Peter Xu
2017-12-19 8:45 ` [Qemu-devel] [RFC v6 27/27] tests: qmp-test: add oob test Peter Xu
2018-01-09 14:52 ` [Qemu-devel] [RFC v6 00/27] QMP: out-of-band (OOB) execution support Stefan Hajnoczi
2018-01-10 4:48 ` Peter Xu
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=20171219084557.9801-23-peterx@redhat.com \
--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 \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.