QMP: out-of-band (OOB) execution support
v4 cover QMP: out-of-band (OOB) execution support
v4:
- drop first patch to fix IOWatchPool [Stefan, Dan]
- add s-o-b where missing, and newly got r-bs
- fix English error in commit msg [Fam]
- some tunes on request-dropped event: [Stefan]
- firstly let 'id' be any type, meanwhile make sure "id" is there as long as OOB is enabled for the monitor.
- some comments fix
- add new command "x-oob-test" for testing oob commands [Stefan]
- simplify the test codes to use new x-oob-test
- flush response queue before cleanup monitors
This series was born from this one:
https://lists.gnu.org/archive/html/qemu-devel/2017-08/msg04310.html
The idea comes from Markus Armbruster and the discussion we had in the thread. It's not a super ideal solution (I believe Markus had been thinking hard to keep everything in order meanwhile trying to satisfy the migration requirement), but AFAIU it's currently the best.
What is OOB?
============
It's the shortcut of Out-Of-Band execution, its name is given by Markus. It's a way to quickly execute a QMP request. Say, originally QMP is going throw these steps:
JSON Parser --> QMP Dispatcher --> Respond
/|\ (2) (3) |
(1) | \|/ (4)
+--------- main thread --------+The requests are executed by the so-called QMP-dispatcher after the JSON is parsed. If OOB is on, we run the command directly in the parser and quickly returns.
This series changed the QMP handling logic by moving the command parsing and responding phases into IOThreads, so to be more accurate, after the series the above graph would change into this:
queue/kick queue/kick
JSON Parser ======> QMP Dispatcher =====> Responder
/|\ | (3) /|\ | (4) | /|\
(1) | | (2) | | | |
| | | \|/ (6)| |(5)
| | main thread | |
| | | |
| +--------> monitor IO thread <-------+ |
+-----------/ \----------+New Interfaces
==============
QMP Introspection Changes
-------------------------
When do query-qmp-schema, we were getting something like:
{"name": "migrate-incoming", "ret-type": "17",
"meta-type": "command", "arg-type": "89"}
Now we will get a new key named "allow-oob":
{"name": "migrate-incoming", "ret-type": "17", "allow-oob": true,
"meta-type": "command", "arg-type": "89"}
Which shows whether a command supports OOB.
QMP Negociation Changes
-----------------------
We were running "qmp_capabilities" always without parameters like:
{"execute": "qmp_capabilities"}
Now we can enable capabilities (we don't have any capability before this series) like OOB using:
{"execute": "qmp_capabilities", "arguments": {"enable": ["oob"]}}
Only after we explicitly enable OOB capability can we send requests in OOB manner. Otherwise we'll have exactly the same QMP session as before, just like when OOB is not there.
When OOB is enabled, it's possible that OOB reply reaches faster than previous command, so clients should be prepared.
Trigger OOB execution
---------------------
Let's take migrate-incoming as example. The old command looks like:
{"execute": "migrate-incoming", "arguments" : {"uri": "xxxxxx"}}
To execute a command with OOB execution, we need to specify it in the QMP request in the extra "control" key:
{"execute": "migrate-incoming", "arguments" : {"uri": "xxxxxx"},
"control" { "run-oob": true } }
Then the command will be run in parser, and it can preempt other commands.
Others
=================
The last patch of OOB test may need some attention. I used dump-guest-memory as a time-consuming command to test whether OOB is working, and the only command I can test now is "migrate-incoming". I hope that is a "okay" solution for unit tests. Any other suggestions on that would be welcomed.
Please review. Thanks.
Peter Xu (27):
qobject: introduce qstring_get_try_str()
qobject: introduce qobject_get_try_str()
qobject: let object_property_get_str() use new API
monitor: move skip_flush into monitor_data_init
qjson: add "opaque" field to JSONMessageParser
monitor: move the cur_mon hack deeper for QMP
monitor: unify global init
monitor: let mon_list be tail queue
monitor: create monitor dedicate iothread
monitor: allow to use IO thread for parsing
qmp: introduce QMPCapability
qmp: negociate QMP capabilities
qmp: introduce some capability helpers
monitor: introduce monitor_qmp_respond()
monitor: let monitor_{suspend|resume} thread safe
monitor: separate QMP parser and dispatcher
qmp: add new event "request-dropped"
monitor: send event when request queue full
qapi: introduce new cmd option "allow-oob"
qmp: support out-of-band (oob) execution
qmp: let migrate-incoming allow out-of-band
qmp: isolate responses into io thread
monitor: enable IO thread for (qmp & !mux) typed
qmp: add command "x-oob-test"
docs: update QMP documents for OOB commands
tests: qmp-test: verify command batching
tests: qmp-test: add oob test
docs/devel/qapi-code-gen.txt | 51 +++- docs/interop/qmp-spec.txt | 35 ++- include/monitor/monitor.h | 2 +- include/qapi/qmp/dispatch.h | 2 + include/qapi/qmp/json-streamer.h | 10 +- include/qapi/qmp/qstring.h | 2 + monitor.c | 555 ++++++++++++++++++++++++++++++++++----- qapi-schema.json | 80 +++++- qapi/introspect.json | 6 +- qapi/migration.json | 3 +- qapi/qmp-dispatch.c | 39 +++ qga/main.c | 5 +- qmp.c | 16 ++ qobject/json-streamer.c | 6 +- qobject/qjson.c | 5 +- qobject/qstring.c | 21 ++ qom/object.c | 9 +- scripts/qapi-commands.py | 19 +- scripts/qapi-introspect.py | 10 +- scripts/qapi.py | 15 +- scripts/qapi2texi.py | 2 +- tests/libqtest.c | 5 +- tests/qapi-schema/test-qapi.py | 2 +- tests/qmp-test.c | 90 ++++++- trace-events | 2 + vl.c | 3 +- 26 files changed, 874 insertions(+), 121 deletions(-)
Signature · 1 line
2.13.6
RFC v4 1/27 qobject: introduce qstring_get_try_str()
The only difference from qstring_get_str() is that it allows the qstring to be NULL. If so, NULL is returned.
--- include/qapi/qmp/qstring.h | 1 + qobject/qstring.c | 10 ++++++++++ 2 files changed, 11 insertions(+)
include/qapi/qmp/qstring.h +1 -0
@@ -27,6 +27,7 @@ QString *qstring_from_str(const char *str);QString *qstring_from_substr (const char *str,int start,int end);size_t qstring_get_length (const QString *qstring);const char *qstring_get_str (const QString *qstring); +const char *qstring_get_try_str (const QString *qstring);void qstring_append_int (QString *qstring,int64_t value);void qstring_append (QString *qstring,const char *str);void qstring_append_chr (QString *qstring,int c);
qobject/qstring.c +10 -0
@@ -129,6 +129,16 @@ const char *qstring_get_str(const QString *qstring) }/** +* qstring_get_try_str(): Return a pointer to the stored string +* +* NOTE: will return NULL if qstring is not provided. +*/ +const char *qstring_get_try_str (const QString *qstring) +{ +return qstring ?qstring_get_str (qstring) :NULL ; +} + +/** * qstring_destroy_obj(): Free all memory allocated by a QString * object */
Signature · 1 line
2.13.6
RFC v4 2/27 qobject: introduce qobject_get_try_str()
In reply to Peter XuA quick way to fetch string from qobject when it's a QString.
--- include/qapi/qmp/qstring.h | 1 + qobject/qstring.c | 11 +++++++++++ 2 files changed, 12 insertions(+)
include/qapi/qmp/qstring.h +1 -0
@@ -28,6 +28,7 @@ QString *qstring_from_substr(const char *str, int start, int end);size_t qstring_get_length (const QString *qstring);const char *qstring_get_str (const QString *qstring);const char *qstring_get_try_str (const QString *qstring); +const char *qobject_get_try_str (const QObject *qstring);void qstring_append_int (QString *qstring,int64_t value);void qstring_append (QString *qstring,const char *str);void qstring_append_chr (QString *qstring,int c);
qobject/qstring.c +11 -0
@@ -139,6 +139,17 @@ const char *qstring_get_try_str(const QString *qstring) }/** +* qobject_get_try_str(): Return a pointer of the backstore string +* +* NOTE: the string will only be returned if the object is valid, and +* its type is QString, otherwise NULL is returned. +*/ +const char *qobject_get_try_str (const QObject *qstring) +{ +return qstring_get_try_str (qobject_to_qstring (qstring)); +} + +/** * qstring_destroy_obj(): Free all memory allocated by a QString * object */
Signature · 1 line
2.13.6
RFC v4 3/27 qobject: let object_property_get_str() use new API
In reply to Peter XuWe can simplify object_property_get_str() using the new qobject_get_try_str().
--- qom/object.c | 9 +++------ 1 file changed, 3 insertions(+), 6 deletions(-)
qom/object.c +3 -6
@@ -1116,18 +1116,15 @@ char *object_property_get_str(Object *obj, const char *name, Error **errp) {QObject *ret =object_property_get_qobject (obj, name, errp); -QString *qstring;char *retval;if (!ret) {return NULL ; } - qstring =qobject_to_qstring (ret); -if (!qstring) { + + retval =g_strdup (qobject_get_try_str (ret)); +if (!retval) {error_setg (errp,QERR_INVALID_PARAMETER_TYPE , name,"string" ); - retval =NULL ; - }else { - retval =g_strdup (qstring_get_str (qstring)); }qobject_decref (ret);
Signature · 1 line
2.13.6
RFC v4 4/27 monitor: move skip_flush into monitor_data_init
In reply to Peter XuIt's part of the data init. Collect it.
--- monitor.c | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-)
monitor.c +4 -4
@@ -568,13 +568,14 @@ static void monitor_qapi_event_init(void)static void handle_hmp_command (Monitor *mon,const char *cmdline); -static void monitor_data_init (Monitor *mon) +static void monitor_data_init (Monitor *mon,bool skip_flush) {memset (mon,0 ,sizeof (Monitor));qemu_mutex_init (&mon->out_lock); mon->outbuf =qstring_new ();/* Use *mon_cmds by default. */ mon->cmd_table = mon_cmds; + mon->skip_flush = skip_flush; }static void monitor_data_destroy (Monitor *mon)
@@ -595,8 +596,7 @@ char *qmp_human_monitor_command(const char *command_line, bool has_cpu_index,char *output =NULL ;Monitor *old_mon, hmp; -monitor_data_init (&hmp); - hmp.skip_flush = true; +monitor_data_init (&hmp, true); old_mon = cur_mon; cur_mon = &hmp;
@@ -4089,7 +4089,7 @@ void monitor_init(Chardev *chr, int flags) } mon =g_malloc (sizeof (*mon)); -monitor_data_init (mon); +monitor_data_init (mon, false);qemu_chr_fe_init (&mon->chr, chr, &error_abort); mon->flags = flags;
Signature · 1 line
2.13.6
RFC v4 5/27 qjson: add "opaque" field to JSONMessageParser
In reply to Peter XuIt'll be passed to emit() as well when it happens. Since at it, add a typedef for the emitter function.
--- include/qapi/qmp/json-streamer.h | 10 ++++++++-- monitor.c | 7 ++++--- qga/main.c | 5 +++-- qobject/json-streamer.c | 6 ++++-- qobject/qjson.c | 5 +++-- tests/libqtest.c | 5 +++-- 6 files changed, 25 insertions(+), 13 deletions(-)
include/qapi/qmp/json-streamer.h +8 -2
@@ -23,9 +23,14 @@ typedef struct JSONToken {char str[]; } JSONToken; +struct JSONMessageParser ; +typedef void (*JSONMessageEmitFunc )(struct JSONMessageParser *parser, +GQueue *tokens,void *opaque); + typedef struct JSONMessageParser { - void (*emit)(struct JSONMessageParser *parser, GQueue *tokens); + JSONMessageEmitFunc emit; + void *opaque; JSONLexer lexer; int brace_count; int bracket_count;
@@ -34,7 +39,8 @@ typedef struct JSONMessageParser } JSONMessageParser;void json_message_parser_init (JSONMessageParser *parser, -void (*func)(JSONMessageParser *,GQueue *)); +JSONMessageEmitFunc func, +void *opaque);int json_message_parser_feed (JSONMessageParser *parser,const char *buffer,size_t size);
monitor.c +4 -3
@@ -3808,7 +3808,8 @@ static int monitor_can_read(void *opaque)return (mon->suspend_cnt ==0 ) ?1 :0 ; } -static void handle_qmp_command (JSONMessageParser *parser,GQueue *tokens) +static void handle_qmp_command (JSONMessageParser *parser,GQueue *tokens, +void *opaque) {QObject *req, *rsp =NULL , *id =NULL ;QDict *qdict =NULL ;
@@ -3955,7 +3956,7 @@ static void monitor_qmp_event(void *opaque, int event)break ;case CHR_EVENT_CLOSED :json_message_parser_destroy (&mon->qmp.parser); -json_message_parser_init (&mon->qmp.parser, handle_qmp_command); +json_message_parser_init (&mon->qmp.parser, handle_qmp_command,NULL ); mon_refcount--;monitor_fdsets_cleanup ();break ;
@@ -4105,7 +4106,7 @@ void monitor_init(Chardev *chr, int flags)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); +json_message_parser_init (&mon->qmp.parser, handle_qmp_command,NULL ); }else {qemu_chr_fe_set_handlers (&mon->chr, monitor_can_read, monitor_read, monitor_event,NULL , mon,NULL , true);
qga/main.c +3 -2
@@ -593,7 +593,8 @@ static void process_command(GAState *s, QDict *req) }/* handle requests/control events coming in over the channel */ -static void process_event (JSONMessageParser *parser,GQueue *tokens) +static void process_event (JSONMessageParser *parser,GQueue *tokens, +void *opaque) {GAState *s =container_of (parser, GAState, parser);QDict *qdict;
@@ -1320,7 +1321,7 @@ static int run_agent(GAState *s, GAConfig *config, int socket_activation) s->command_state =ga_command_state_new ();ga_command_state_init (s, s->command_state);ga_command_state_init_all (s->command_state); -json_message_parser_init (&s->parser, process_event); +json_message_parser_init (&s->parser, process_event,NULL );#ifndef _WIN32if (!register_signal_handlers ()) {
qobject/json-streamer.c +4 -2
@@ -102,18 +102,20 @@ out_emit:*/ tokens = parser->tokens; parser->tokens =g_queue_new (); - parser->emit (parser, tokens); + parser->emit (parser, tokens, parser->opaque); parser->token_size =0 ; }void json_message_parser_init (JSONMessageParser *parser, -void (*func)(JSONMessageParser *,GQueue *)) +JSONMessageEmitFunc func, +void *opaque) { parser->emit = func; parser->brace_count =0 ; parser->bracket_count =0 ; parser->tokens =g_queue_new (); parser->token_size =0 ; + parser->opaque = opaque;json_lexer_init (&parser->lexer, json_message_process_token); }
qobject/qjson.c +3 -2
@@ -28,7 +28,8 @@ typedef struct JSONParsingStateError *err; } JSONParsingState; -static void parse_json (JSONMessageParser *parser,GQueue *tokens) +static void parse_json (JSONMessageParser *parser,GQueue *tokens, +void *opaque) {JSONParsingState *s =container_of (parser, JSONParsingState, parser);
@@ -41,7 +42,7 @@ QObject *qobject_from_jsonv(const char *string, va_list *ap, Error **errp) state.ap = ap; -json_message_parser_init (&state.parser, parse_json); +json_message_parser_init (&state.parser, parse_json,NULL );json_message_parser_feed (&state.parser, string,strlen (string));json_message_parser_flush (&state.parser);json_message_parser_destroy (&state.parser);
tests/libqtest.c +3 -2
@@ -412,7 +412,8 @@ typedef struct {QDict *response; } QMPResponseParser; -static void qmp_response (JSONMessageParser *parser,GQueue *tokens) +static void qmp_response (JSONMessageParser *parser,GQueue *tokens, +void *opaque) {QMPResponseParser *qmp =container_of (parser, QMPResponseParser, parser);QObject *obj;
@@ -434,7 +435,7 @@ QDict *qmp_fd_receive(int fd)bool log =getenv ("QTEST_LOG" ) !=NULL ; qmp.response =NULL ; -json_message_parser_init (&qmp.parser, qmp_response); +json_message_parser_init (&qmp.parser, qmp_response,NULL );while (!qmp.response) {ssize_t len;char c;
Signature · 1 line
2.13.6
RFC v4 6/27 monitor: move the cur_mon hack deeper for QMP
In reply to Peter XuIn monitor_qmp_read(), we have the hack to temporarily replace the cur_mon pointer. Now we move this hack deeper inside the QMP dispatcher routine since the Monitor pointer can be passed in to that using the new JSON Parser opaque field now.
This does not make much sense as a single patch. However, this will be a big step for the next patch, when the QMP dispatcher routine will be split from the QMP parser.
--- monitor.c | 19 ++++++++++--------- 1 file changed, 10 insertions(+), 9 deletions(-)
monitor.c +10 -9
@@ -3813,7 +3813,7 @@ static void handle_qmp_command(JSONMessageParser *parser, GQueue *tokens, {QObject *req, *rsp =NULL , *id =NULL ;QDict *qdict =NULL ; -Monitor *mon = cur_mon; +Monitor *mon = opaque, *old_mon;Error *err =NULL ; req =json_parser_parse_err (tokens,NULL , &err);
@@ -3838,8 +3838,13 @@ static void handle_qmp_command(JSONMessageParser *parser, GQueue *tokens,QDECREF (req_json); } + old_mon = cur_mon; + cur_mon = mon; + rsp =qmp_dispatch (cur_mon->qmp.commands, req); + cur_mon = old_mon; +if (mon->qmp.commands == &qmp_cap_negotiation_commands) { qdict =qdict_get_qdict (qobject_to_qdict (rsp),"error" ); if (qdict
@@ -3876,13 +3881,9 @@ err_out:static void monitor_qmp_read (void *opaque,const uint8_t *buf,int size) { -Monitor *old_mon = cur_mon; - - cur_mon = opaque; - -json_message_parser_feed (&cur_mon->qmp.parser, (const char *) buf, size); +Monitor *mon = opaque; - cur_mon = old_mon; +json_message_parser_feed (&mon->qmp.parser, (const char *) buf, size); }static void monitor_read (void *opaque,const uint8_t *buf,int size)
@@ -3956,7 +3957,7 @@ static void monitor_qmp_event(void *opaque, int event)break ;case CHR_EVENT_CLOSED :json_message_parser_destroy (&mon->qmp.parser); -json_message_parser_init (&mon->qmp.parser, handle_qmp_command,NULL ); +json_message_parser_init (&mon->qmp.parser, handle_qmp_command, mon); mon_refcount--;monitor_fdsets_cleanup ();break ;
@@ -4106,7 +4107,7 @@ void monitor_init(Chardev *chr, int flags)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,NULL ); +json_message_parser_init (&mon->qmp.parser, handle_qmp_command, mon); }else {qemu_chr_fe_set_handlers (&mon->chr, monitor_can_read, monitor_read, monitor_event,NULL , mon,NULL , true);
Signature · 1 line
2.13.6
RFC v4 7/27 monitor: unify global init
In reply to Peter XuThere are many places for monitor init its globals, at least:
- monitor_init_qmp_commands() at the very beginning
- single function to init monitor_lock
- in the first entry of monitor_init() using "is_first_init"
Unify them a bit.
--- include/monitor/monitor.h | 2 +- monitor.c | 25 ++++++++++--------------- vl.c | 3 ++- 3 files changed, 13 insertions(+), 17 deletions(-)
include/monitor/monitor.h +1 -1
@@ -16,7 +16,7 @@ extern Monitor *cur_mon;bool monitor_cur_is_qmp (void ); -void monitor_init_qmp_commands (void ); +void monitor_init_globals (void );void monitor_init (Chardev *chr,int flags);void monitor_cleanup (void );
monitor.c +10 -15
@@ -1001,7 +1001,7 @@ static void qmp_unregister_commands_hack(void)#endif } -void monitor_init_qmp_commands (void ) +static void monitor_init_qmp_commands (void ) {/* * Two command lists:
@@ -4034,6 +4034,14 @@ static void sortcmdlist(void)qsort ((void *)info_cmds, array_num, elem_size, compare_mon_cmd); } +void monitor_init_globals (void ) +{ +monitor_init_qmp_commands (); +monitor_qapi_event_init (); +sortcmdlist (); +qemu_mutex_init (&monitor_lock); +} +/* These functions just adapt the readline interface in a typesafe way. We * could cast function pointers but that discards compiler checks. */
@@ -4074,23 +4082,10 @@ void error_vprintf_unless_qmp(const char *fmt, va_list ap) } } -static void __attribute__((constructor))monitor_lock_init (void ) -{ -qemu_mutex_init (&monitor_lock); -} -void monitor_init (Chardev *chr,int flags) { -static int is_first_init =1 ; -Monitor *mon; - -if (is_first_init) { -monitor_qapi_event_init (); -sortcmdlist (); - is_first_init =0 ; - } +Monitor *mon =g_malloc (sizeof (*mon)); - mon =g_malloc (sizeof (*mon));monitor_data_init (mon, false);qemu_chr_fe_init (&mon->chr, chr, &error_abort);
vl.c +2 -1
@@ -3144,7 +3144,6 @@ int main(int argc, char **argv, char **envp)qemu_init_exec_dir (argv[0 ]);module_call_init (MODULE_INIT_QOM ); -monitor_init_qmp_commands ();qemu_add_opts (&qemu_drive_opts);qemu_add_drive_opts (&qemu_legacy_drive_opts);
@@ -4692,6 +4691,8 @@ int main(int argc, char **argv, char **envp)parse_numa_opts (current_machine); +monitor_init_globals (); +if (qemu_opts_foreach (qemu_find_opts ("mon" ), mon_init_func,NULL ,NULL )) {exit (1 );
Signature · 1 line
2.13.6
RFC v4 8/27 monitor: let mon_list be tail queue
In reply to Peter XuIt was QLIST. I want to use this list to do monitor priority job later, which need tail insertion ability. So switching to a tail queue.
--- monitor.c | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-)
monitor.c +5 -5
@@ -205,7 +205,7 @@ struct Monitor {void *password_opaque;mon_cmd_t *cmd_table; QLIST_HEAD(,mon_fd_t) fds; -QLIST_ENTRY (Monitor) entry; +QTAILQ_ENTRY (Monitor) entry; };/* QMP checker flags */
@@ -214,7 +214,7 @@ struct Monitor {/* Protects mon_list, monitor_event_state. */ static QemuMutex monitor_lock; -static QLIST_HEAD(mon_list, Monitor) mon_list; +static QTAILQ_HEAD(mon_list, Monitor) mon_list; static QLIST_HEAD(mon_fdsets, MonFdset) mon_fdsets;static int mon_refcount;
@@ -415,7 +415,7 @@ static void monitor_qapi_event_emit(QAPIEvent event, QDict *qdict)Monitor *mon;trace_monitor_protocol_event_emit (event, qdict); - QLIST_FOREACH(mon, &mon_list, entry) { + QTAILQ_FOREACH(mon, &mon_list, entry) {if (monitor_is_qmp (mon) && mon->qmp.commands != &qmp_cap_negotiation_commands) {monitor_json_emitter (mon,QOBJECT (qdict));
@@ -4118,8 +4118,8 @@ void monitor_cleanup(void)Monitor *mon, *next;qemu_mutex_lock (&monitor_lock); - QLIST_FOREACH_SAFE(mon, &mon_list, entry, next) { -QLIST_REMOVE (mon, entry); + QTAILQ_FOREACH_SAFE(mon, &mon_list, entry, next) { +QTAILQ_REMOVE (&mon_list, mon, entry);monitor_data_destroy (mon);g_free (mon); }
Signature · 1 line
2.13.6
RFC v4 9/27 monitor: create monitor dedicate iothread
In reply to Peter XuCreate one IOThread for the monitors, prepared to handle all the input/output IOs using existing iothread framework.
--- monitor.c | 29 +++++++++++++++++++++++++++++ 1 file changed, 29 insertions(+)
monitor.c +29 -0
@@ -76,6 +76,7 @@#include "qmp-introspect.h" #include "sysemu/qtest.h" #include "sysemu/cpus.h" +#include "sysemu/iothread.h" #include "qemu/cutils.h" #include "qapi/qmp/dispatch.h"
@@ -208,6 +209,12 @@ struct Monitor {QTAILQ_ENTRY (Monitor) entry; }; +struct MonitorGlobal { +IOThread *mon_iothread; +}; + +static struct MonitorGlobal mon_global; +/* QMP checker flags */ #define QMP_ACCEPT_UNKNOWNS 1
@@ -4034,12 +4041,24 @@ 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 void monitor_iothread_init (void ) +{ + mon_global.mon_iothread =iothread_create ("monitor_iothread" , + &error_abort); +} +void monitor_init_globals (void ) {monitor_init_qmp_commands ();monitor_qapi_event_init ();sortcmdlist ();qemu_mutex_init (&monitor_lock); +monitor_iothread_init (); }/* These functions just adapt the readline interface in a typesafe way. We
@@ -4117,6 +4136,13 @@ void monitor_cleanup(void) {Monitor *mon, *next; +/* +* We need to explicitly stop the iothread (but not destroy it), +* cleanup the monitor resources, then destroy the iothread. See +* again on the glib bug mentioned in 2b316774f6 for a reason. +*/ +iothread_stop (mon_global.mon_iothread); +qemu_mutex_lock (&monitor_lock); QTAILQ_FOREACH_SAFE(mon, &mon_list, entry, next) {QTAILQ_REMOVE (&mon_list, mon, entry);
@@ -4124,6 +4150,9 @@ void monitor_cleanup(void)g_free (mon); }qemu_mutex_unlock (&monitor_lock); + +iothread_destroy (mon_global.mon_iothread); + mon_global.mon_iothread =NULL ; }QemuOptsList qemu_mon_opts = {
Signature · 1 line
2.13.6
Re: [Qemu-devel] [RFC v4 09/27] monitor: create monitor dedicate iothread
Quoted 36 lines · * Peter Xu ([email protected]) wrote:
Create one IOThread for the monitors, prepared to handle all the input/output IOs using existing iothread framework.
Signed-off-by Peter Xu <[email protected]>--- monitor.c | 29 +++++++++++++++++++++++++++++ 1 file changed, 29 insertions(+)monitor.c +7
-0@@ -76,6 +76,7 @@#include "qmp-introspect.h" #include "sysemu/qtest.h" #include "sysemu/cpus.h" +#include "sysemu/iothread.h" #include "qemu/cutils.h" #include "qapi/qmp/dispatch.h" @@ -208,6 +209,12 @@ struct Monitor {QTAILQ_ENTRY (Monitor) entry; }; +struct MonitorGlobal { +IOThread *mon_iothread; +}; + +static struct MonitorGlobal mon_global; +/* QMP checker flags */ #define QMP_ACCEPT_UNKNOWNS 1@@ -4034,12 +4041,24 @@ static void sortcmdlist(void)qsort ((void *)info_cmds, array_num, elem_size, compare_mon_cmd); }
monitor.c static void sortcmdlist(void) · line 4052
Quoted 10 lines
monitor.c +9
-0+static GMainContext *monitor_io_context_get (void ) +{ +return iothread_get_g_main_context (mon_global.mon_iothread); +} + +static void monitor_iothread_init (void ) +{ + mon_global.mon_iothread =iothread_create ("monitor_iothread" , + &error_abort);
That name is one character too long for pthread_setname_np that it ends up being passed too (it's 16 char including the terminator); that probably means the thread ends up unnamed. I suggest you make it "mon_iothread"
Quoted 13 lines
monitor.c +3
-0+} +void monitor_init_globals (void ) {monitor_init_qmp_commands ();monitor_qapi_event_init ();sortcmdlist ();qemu_mutex_init (&monitor_lock); +monitor_iothread_init (); }/* These functions just adapt the readline interface in a typesafe way. We
monitor.c void monitor_cleanup(void) · line 4142
Quoted 7 lines
monitor.c +4
-0@@ -4117,6 +4136,13 @@ void monitor_cleanup(void) {Monitor *mon, *next; +/* +* We need to explicitly stop the iothread (but not destroy it), +* cleanup the monitor resources, then destroy the iothread. See +* again on the glib bug mentioned in 2b316774f6 for a reason.
I wonder if that bug is still live? 2b316774f6 says that:
'glib developers found and fixed the deadlock as part of implementing
child sources.'
but doesn't say which glib version that was fixed in; we have
increased the minimum glib version we support since 2013, so maybe...
Dave
Quoted 19 lines
monitor.c +6
-0+*/ +iothread_stop (mon_global.mon_iothread); +qemu_mutex_lock (&monitor_lock); QTAILQ_FOREACH_SAFE(mon, &mon_list, entry, next) {QTAILQ_REMOVE (&mon_list, mon, entry);@@ -4124,6 +4150,9 @@ void monitor_cleanup(void)g_free (mon); }qemu_mutex_unlock (&monitor_lock); + +iothread_destroy (mon_global.mon_iothread); + mon_global.mon_iothread =NULL ; }QemuOptsList qemu_mon_opts = {Signature · 1 line
2.13.6
--
Dr. David Alan Gilbert / [email protected] / Manchester, UK
Re: [Qemu-devel] [RFC v4 09/27] monitor: create monitor dedicate iothread
Quoted 69 lines · * Dr. David Alan Gilbert ([email protected]) wrote:
Quoted 36 lines · * Peter Xu ([email protected]) wrote:
Create one IOThread for the monitors, prepared to handle all the input/output IOs using existing iothread framework.
Signed-off-by Peter Xu <[email protected]>--- monitor.c | 29 +++++++++++++++++++++++++++++ 1 file changed, 29 insertions(+)monitor.c +7
-0@@ -76,6 +76,7 @@#include "qmp-introspect.h" #include "sysemu/qtest.h" #include "sysemu/cpus.h" +#include "sysemu/iothread.h" #include "qemu/cutils.h" #include "qapi/qmp/dispatch.h" @@ -208,6 +209,12 @@ struct Monitor {QTAILQ_ENTRY (Monitor) entry; }; +struct MonitorGlobal { +IOThread *mon_iothread; +}; + +static struct MonitorGlobal mon_global; +/* QMP checker flags */ #define QMP_ACCEPT_UNKNOWNS 1@@ -4034,12 +4041,24 @@ static void sortcmdlist(void)qsort ((void *)info_cmds, array_num, elem_size, compare_mon_cmd); }monitor.c static void sortcmdlist(void) · line 4052
Quoted 10 lines
monitor.c +9
-0+static GMainContext *monitor_io_context_get (void ) +{ +return iothread_get_g_main_context (mon_global.mon_iothread); +} + +static void monitor_iothread_init (void ) +{ + mon_global.mon_iothread =iothread_create ("monitor_iothread" , + &error_abort);That name is one character too long for
pthread_setname_npthat it ends up being passed too (it's 16 char including the terminator); that probably means the thread ends up unnamed. I suggest you make it "mon_iothread"Quoted 16 lines
monitor.c +3
-0+} +void monitor_init_globals (void ) {monitor_init_qmp_commands ();monitor_qapi_event_init ();sortcmdlist ();qemu_mutex_init (&monitor_lock); +monitor_iothread_init (); }/* These functions just adapt the readline interface in a typesafe way. We @@ -4117,6 +4136,13 @@ void monitor_cleanup(void) {Monitor *mon, *next;
Quoted 10 lines
monitor.c void monitor_cleanup(void) · line 4142
Quoted 4 lines
monitor.c +4
-0+/* +* We need to explicitly stop the iothread (but not destroy it), +* cleanup the monitor resources, then destroy the iothread. See +* again on the glib bug mentioned in 2b316774f6 for a reason. I wonder if that bug is still live?
2b316774f6says that:
'glib developers found and fixed the deadlock as part of implementing
child sources.'
but doesn't say which glib version that was fixed in; we have
increased the minimum glib version we support since 2013, so maybe...
Paolo says it wasn't fixed until 2.28 and we still allow 2.22 ; so a little way before we can declare that one dead.
Dave
Quoted 17 lines
Dave
Quoted 15 lines
monitor.c +6
-0+*/ +iothread_stop (mon_global.mon_iothread); +qemu_mutex_lock (&monitor_lock); QTAILQ_FOREACH_SAFE(mon, &mon_list, entry, next) {QTAILQ_REMOVE (&mon_list, mon, entry);@@ -4124,6 +4150,9 @@ void monitor_cleanup(void)g_free (mon); }qemu_mutex_unlock (&monitor_lock); + +iothread_destroy (mon_global.mon_iothread); + mon_global.mon_iothread =NULL ; }
Quoted 6 lines
Quoted 4 lines
monitor.c +0
-0QemuOptsList qemu_mon_opts = {Signature · 1 line
2.13.6--
Dr. David Alan Gilbert / [email protected] / Manchester, UK
--
Dr. David Alan Gilbert / [email protected] / Manchester, UK
Re: [Qemu-devel] [RFC v4 09/27] monitor: create monitor dedicate iothread
Quoted 81 lines · Dr. David Alan Gilbert
Quoted 69 lines · * Dr. David Alan Gilbert ([email protected]) wrote:
Quoted 36 lines · * Peter Xu ([email protected]) wrote:
Create one IOThread for the monitors, prepared to handle all the input/output IOs using existing iothread framework.
Signed-off-by Peter Xu <[email protected]>--- monitor.c | 29 +++++++++++++++++++++++++++++ 1 file changed, 29 insertions(+)monitor.c +7
-0@@ -76,6 +76,7 @@#include "qmp-introspect.h" #include "sysemu/qtest.h" #include "sysemu/cpus.h" +#include "sysemu/iothread.h" #include "qemu/cutils.h" #include "qapi/qmp/dispatch.h" @@ -208,6 +209,12 @@ struct Monitor {QTAILQ_ENTRY (Monitor) entry; }; +struct MonitorGlobal { +IOThread *mon_iothread; +}; + +static struct MonitorGlobal mon_global; +/* QMP checker flags */ #define QMP_ACCEPT_UNKNOWNS 1@@ -4034,12 +4041,24 @@ static void sortcmdlist(void)qsort ((void *)info_cmds, array_num, elem_size, compare_mon_cmd); }monitor.c static void sortcmdlist(void) · line 4052
Quoted 10 lines
monitor.c +9
-0+static GMainContext *monitor_io_context_get (void ) +{ +return iothread_get_g_main_context (mon_global.mon_iothread); +} + +static void monitor_iothread_init (void ) +{ + mon_global.mon_iothread =iothread_create ("monitor_iothread" , + &error_abort);That name is one character too long for
pthread_setname_npthat it ends up being passed too (it's 16 char including the terminator); that probably means the thread ends up unnamed. I suggest you make it "mon_iothread"Quoted 16 lines
monitor.c +3
-0+} +void monitor_init_globals (void ) {monitor_init_qmp_commands ();monitor_qapi_event_init ();sortcmdlist ();qemu_mutex_init (&monitor_lock); +monitor_iothread_init (); }/* These functions just adapt the readline interface in a typesafe way. We @@ -4117,6 +4136,13 @@ void monitor_cleanup(void) {Monitor *mon, *next;Quoted 10 lines
monitor.c void monitor_cleanup(void) · line 4142
Quoted 4 lines
monitor.c +4
-0+/* +* We need to explicitly stop the iothread (but not destroy it), +* cleanup the monitor resources, then destroy the iothread. See +* again on the glib bug mentioned in 2b316774f6 for a reason. I wonder if that bug is still live?
2b316774f6says that:
'glib developers found and fixed the deadlock as part of implementing
child sources.'
but doesn't say which glib version that was fixed in; we have
increased the minimum glib version we support since 2013, so maybe...
Quoted 2 lines
Paolo says it wasn't fixed until 2.28 and we still allow 2.22 ; so a little way before we can declare that one dead.
Please update the comment to mention that we can remove the hack in 2.28, since I bet we'll forget about this by the time that time comes :=)
Regards,
Daniel
Signature · 3 lines
|: https://berrange.com -o- https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o- https://fstop138.berrange.com :| |: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|
Re: [Qemu-devel] [RFC v4 09/27] monitor: create monitor dedicate iothread
Quoted 40 lines · Daniel P. Berrange
Quoted 39 lines · Dr. David Alan Gilbert
Quoted 38 lines · * Dr. David Alan Gilbert ([email protected]) wrote:
Quoted 37 lines · * Peter Xu ([email protected]) wrote:
Create one IOThread for the monitors, prepared to handle all the input/output IOs using existing iothread framework.
Signed-off-by Peter Xu <[email protected]>--- monitor.c | 29 +++++++++++++++++++++++++++++ 1 file changed, 29 insertions(+)monitor.c +7
-0@@ -76,6 +76,7 @@#include "qmp-introspect.h" #include "sysemu/qtest.h" #include "sysemu/cpus.h" +#include "sysemu/iothread.h" #include "qemu/cutils.h" #include "qapi/qmp/dispatch.h" @@ -208,6 +209,12 @@ struct Monitor {QTAILQ_ENTRY (Monitor) entry; }; +struct MonitorGlobal { +IOThread *mon_iothread; +}; + +static struct MonitorGlobal mon_global; +/* QMP checker flags */ #define QMP_ACCEPT_UNKNOWNS 1@@ -4034,12 +4041,24 @@ static void sortcmdlist(void)qsort ((void *)info_cmds, array_num, elem_size, compare_mon_cmd); }
Quoted 14 lines
Quoted 6 lines
Quoted 6 lines
Quoted 6 lines
monitor.c +6
-0+static GMainContext *monitor_io_context_get (void ) +{ +return iothread_get_g_main_context (mon_global.mon_iothread); +} + +static void monitor_iothread_init (void )Quoted 8 lines
Quoted 8 lines
monitor.c static void sortcmdlist(void) · line 4052
Quoted 3 lines
monitor.c +3
-0+{ + mon_global.mon_iothread =iothread_create ("monitor_iothread" , + &error_abort);That name is one character too long for
pthread_setname_npthat it ends up being passed too (it's 16 char including the terminator); that probably means the thread ends up unnamed. I suggest you make it "mon_iothread"
Will do.
Quoted 28 lines
Quoted 28 lines
Quoted 27 lines
Quoted 14 lines
monitor.c +3
-0+} +void monitor_init_globals (void ) {monitor_init_qmp_commands ();monitor_qapi_event_init ();sortcmdlist ();qemu_mutex_init (&monitor_lock); +monitor_iothread_init (); }/* These functions just adapt the readline interface in a typesafe way. We monitor.c void monitor_cleanup(void) · line 4142
Quoted 7 lines
monitor.c +4
-0@@ -4117,6 +4136,13 @@ void monitor_cleanup(void) {Monitor *mon, *next; +/* +* We need to explicitly stop the iothread (but not destroy it), +* cleanup the monitor resources, then destroy the iothread. See +* again on the glib bug mentioned in 2b316774f6 for a reason. I wonder if that bug is still live?
2b316774f6says that:
'glib developers found and fixed the deadlock as part of implementing
child sources.'
but doesn't say which glib version that was fixed in; we have
increased the minimum glib version we support since 2013, so maybe...
Quoted 6 lines
Quoted 2 lines
Paolo says it wasn't fixed until 2.28 and we still allow 2.22 ; so a little way before we can declare that one dead.
Please update the comment to mention that we can remove the hack in 2.28, since I bet we'll forget about this by the time that time comes :=)
Yes worth a comment!
Thanks all.
Signature · 1 line
Peter Xu
RFC v4 10/27 monitor: allow to use IO thread for parsing
In reply to Peter XuFor each Monitor, add one field "use_io_thr" to show whether it will be using the dedicated monitor IO thread to handle input/output. When set, monitor IO parsing work will be offloaded to dedicated monitor IO thread, rather than the original main loop thread.
This only works for QMP. HMP will always be run on main loop thread.
Currently we're still keeping use_io_thr to off always. Will turn it on later at some point.
One thing to mention is that we cannot set use_io_thr for every QMP monitors. The problem is that MUXed typed chardevs may not work well with it now. When MUX is used, frontend of chardev can be the monitor plus something else. The only thing we know would be safe to be run outside main thread so far is the monitor frontend. All the rest of the frontends should still be run in main thread only.
--- monitor.c | 38 ++++++++++++++++++++++++++++++-------- 1 file changed, 30 insertions(+), 8 deletions(-)
monitor.c +30 -8
@@ -191,6 +191,7 @@ struct Monitor {int flags;int suspend_cnt;bool skip_flush; +bool use_io_thr;QemuMutex out_lock;QString *outbuf;
@@ -575,7 +576,8 @@ static void monitor_qapi_event_init(void)static void handle_hmp_command (Monitor *mon,const char *cmdline); -static void monitor_data_init (Monitor *mon,bool skip_flush) +static void monitor_data_init (Monitor *mon,bool skip_flush, +bool use_io_thr) {memset (mon,0 ,sizeof (Monitor));qemu_mutex_init (&mon->out_lock);
@@ -583,6 +585,7 @@ static void monitor_data_init(Monitor *mon, bool skip_flush)/* Use *mon_cmds by default. */ mon->cmd_table = mon_cmds; mon->skip_flush = skip_flush; + mon->use_io_thr = use_io_thr; }static void monitor_data_destroy (Monitor *mon)
@@ -603,7 +606,7 @@ char *qmp_human_monitor_command(const char *command_line, bool has_cpu_index,char *output =NULL ;Monitor *old_mon, hmp; -monitor_data_init (&hmp, true); +monitor_data_init (&hmp, true, false); old_mon = cur_mon; cur_mon = &hmp;
@@ -4104,8 +4107,9 @@ void error_vprintf_unless_qmp(const char *fmt, va_list ap)void monitor_init (Chardev *chr,int flags) {Monitor *mon =g_malloc (sizeof (*mon)); +GMainContext *context; -monitor_data_init (mon, false); +monitor_data_init (mon, false, false);qemu_chr_fe_init (&mon->chr, chr, &error_abort); mon->flags = flags;
@@ -4117,19 +4121,37 @@ void monitor_init(Chardev *chr, int flags)monitor_read_command (mon,0 ); } +if (mon->use_io_thr) { +/* +* When use_io_thr is set, we use the global shared dedicated +* IO thread for this monitor to handle input/output. +*/ + context =monitor_io_context_get (); +/* We should have inited globals before reaching here. */ +assert (context); + }else { +/* The default main loop, which is the main thread */ + context =NULL ; + } + +/* +* Add the monitor before running it (which is triggered by +* qemu_chr_fe_set_handlers), otherwise one monitor may find +* itself not on the mon_list when running. +*/ +qemu_mutex_lock (&monitor_lock); +QTAILQ_INSERT_HEAD (&mon_list, mon, entry); +qemu_mutex_unlock (&monitor_lock); +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); + monitor_qmp_event,NULL , mon, context, true);qemu_chr_fe_set_echo (&mon->chr, true);json_message_parser_init (&mon->qmp.parser, handle_qmp_command, mon); }else {qemu_chr_fe_set_handlers (&mon->chr, monitor_can_read, monitor_read, monitor_event,NULL , mon,NULL , true); } - -qemu_mutex_lock (&monitor_lock); -QLIST_INSERT_HEAD (&mon_list, mon, entry); -qemu_mutex_unlock (&monitor_lock); }void monitor_cleanup (void )
Signature · 1 line
2.13.6
RFC v4 11/27 qmp: introduce QMPCapability
In reply to Peter XuThere was no QMP capabilities defined. Define the first "oob" as capability to allow out-of-band messages.
Also, touch up qmp-test.c to test the new bits.
--- monitor.c | 15 +++++++++++++-- qapi-schema.json | 13 +++++++++++++ tests/qmp-test.c | 10 +++++++++- 3 files changed, 35 insertions(+), 3 deletions(-)
monitor.c +13 -2
@@ -3944,12 +3944,23 @@ void monitor_resume(Monitor *mon)static QObject *get_qmp_greeting (void ) { +QDict *result =qdict_new (), *qmp =qdict_new (); +QList *cap_list =qlist_new ();QObject *ver =NULL ; +QMPCapability cap; + +qdict_put (result,"QMP" , qmp);qmp_marshal_query_version (NULL , &ver,NULL ); +qdict_put_obj (qmp,"version" , ver); + +for (cap =0 ; cap <QMP_CAPABILITY__MAX ; cap++) { +qlist_append (cap_list,qstring_from_str ( +QMPCapability_str (cap))); + } +qdict_put (qmp,"capabilities" , cap_list); -return qobject_from_jsonf ("{'QMP': {'version': %p, 'capabilities': []}}" , - ver); +return QOBJECT (result); }static void monitor_qmp_event (void *opaque,int event)
qapi-schema.json +13 -0
@@ -119,6 +119,19 @@ { 'command': 'qmp_capabilities' } ## +# @QMPCapability: +# +# QMP supported capabilities to be broadcasted to the clients. +# +# @oob: QMP ability to support Out-Of-Band requests. +# +# Since: 2.12 +# +## +{ 'enum': 'QMPCapability', + 'data': [ 'oob' ] } + +## # @VersionTriple: # # A three-part version number.
tests/qmp-test.c +9 -1
@@ -17,6 +17,7 @@#include "qapi/qobject-input-visitor.h" #include "qapi/util.h" #include "qapi/visitor.h" +#include "qapi/qmp/qstring.h" const char common_args[] ="-nodefaults -machine none" ;
@@ -75,6 +76,8 @@ static void test_qmp_protocol(void) {QDict *resp, *q, *ret;QList *capabilities; +const QListEntry *entry; +QString *qstr; global_qtest =qtest_init_without_qmp_handshake (common_args);
@@ -84,7 +87,12 @@ static void test_qmp_protocol(void)g_assert (q);test_version (qdict_get (q,"version" )); capabilities =qdict_get_qlist (q,"capabilities" ); -g_assert (capabilities &&qlist_empty (capabilities)); +g_assert (capabilities); + entry =qlist_first (capabilities); +g_assert (entry); + qstr =qobject_to_qstring (entry->value); +g_assert (qstr); + g_assert_cmpstr(qstring_get_str(qstr), ==, "oob");QDECREF (resp);/* Test valid command before handshake */
Signature · 1 line
2.13.6
RFC v4 12/27 qmp: negociate QMP capabilities
In reply to Peter XuAfter this patch, we will allow QMP clients to enable QMP capabilities when sending the first "qmp_capabilities" command. Originally we are starting QMP session with no arguments like:
{ "execute": "qmp_capabilities" }
Now we can enable some QMP capabilities using (take OOB as example, which is the only one capability that we support):
{ "execute": "qmp_capabilities",
"argument": { "enable": [ "oob" ] } }When the "argument" key is not provided, no capability is enabled.
For capability "oob", the monitor needs to be run on dedicated IO thread, otherwise the command will fail. For example, trying to enable OOB on a MUXed typed QMP monitor will fail.
One thing to mention is that, QMP capabilities are per-monitor, and also when the connection is closed due to some reason, the capabilities will be reset.
--- monitor.c | 57 +++++++++++++++++++++++++++++++++++++++++++++++++++++++- qapi-schema.json | 15 ++++++++++++--- 2 files changed, 68 insertions(+), 4 deletions(-)
monitor.c +56 -1
@@ -167,6 +167,7 @@ typedef struct {* mode. */ QmpCommandList *commands; +bool qmp_caps[QMP_CAPABILITY__MAX ]; } MonitorQMP;/*
@@ -1037,8 +1038,42 @@ static void monitor_init_qmp_commands(void) qmp_marshal_qmp_capabilities, QCO_NO_OPTIONS); } -void qmp_qmp_capabilities (Error **errp) +static void qmp_caps_check (Monitor *mon,QMPCapabilityList *list, +Error **errp) +{ +for (; list; list = list->next) { +assert (list->value <QMP_CAPABILITY__MAX ); +switch (list->value) { +case QMP_CAPABILITY_OOB : +if (!mon->use_io_thr) { +/* +* Out-Of-Band only works with monitors that are +* running on dedicated IOThread. +*/ +error_setg (errp,"This monitor does not support " +"Out-Of-Band (OOB)" ); +return ; + } +break ; +default : +break ; + } + } +} + +/* This function should only be called after capabilities are checked. */ +static void qmp_caps_apply (Monitor *mon,QMPCapabilityList *list) +{ +for (; list; list = list->next) { + mon->qmp.qmp_caps[list->value] = true; + } +} + +void qmp_qmp_capabilities (bool has_enable,QMPCapabilityList *enable, +Error **errp) { +Error *local_err =NULL ; +if (cur_mon->qmp.commands == &qmp_commands) {error_set (errp,ERROR_CLASS_COMMAND_NOT_FOUND , "Capabilities negotiation is already complete, command "
@@ -1046,6 +1081,20 @@ void qmp_qmp_capabilities(Error **errp)return ; } +/* Enable QMP capabilities provided by the guest if applicable. */ +if (has_enable) { +qmp_caps_check (cur_mon, enable, &local_err); +if (local_err) { +/* +* Failed check on either of the capabilities will fail +* the apply of all. +*/ +error_propagate (errp, local_err); +return ; + } +qmp_caps_apply (cur_mon, enable); + } + cur_mon->qmp.commands = &qmp_commands; }
@@ -3963,6 +4012,11 @@ static QObject *get_qmp_greeting(void)return QOBJECT (result); } +static void monitor_qmp_caps_reset (Monitor *mon) +{ +memset (mon->qmp.qmp_caps,0 ,sizeof (mon->qmp.qmp_caps)); +} +static void monitor_qmp_event (void *opaque,int event) {QObject *data;
@@ -3971,6 +4025,7 @@ static void monitor_qmp_event(void *opaque, int event)switch (event) {case CHR_EVENT_OPENED : mon->qmp.commands = &qmp_cap_negotiation_commands; +monitor_qmp_caps_reset (mon); data =get_qmp_greeting ();monitor_json_emitter (mon, data);qobject_decref (data);
qapi-schema.json +12 -3
@@ -102,21 +102,30 @@ # # Enable QMP capabilities. # -# Arguments: None. +# Arguments: +# +# @enable: List of QMPCapabilities to enable, which is optional. +# If not provided, it means no QMP capabilities will be +# enabled. (since 2.12) # # Example: # -# -> { "execute": "qmp_capabilities" } +# -> { "execute": "qmp_capabilities", +# "arguments": { "enable": [ "oob" ] } } # <- { "return": {} } # # Notes: This command is valid exactly when first connecting: it must be # issued before any other command will be accepted, and will fail once the # monitor is accepting other commands. (see qemu docs/interop/qmp-spec.txt) # +# QMP client needs to explicitly enable QMP capabilities, otherwise +# all the QMP capabilities will be turned off by default. +# # Since: 0.13 # ## -{ 'command': 'qmp_capabilities' } +{ 'command': 'qmp_capabilities', + 'data': { '*enable': [ 'QMPCapability' ] } } ## # @QMPCapability:
Signature · 1 line
2.13.6
RFC v4 13/27 qmp: introduce some capability helpers
In reply to Peter XuIntroduce qmp_cap_enabled() and qmp_oob_enabled() helpers.
--- monitor.c | 10 ++++++++++ 1 file changed, 10 insertions(+)
monitor.c +10 -0
@@ -1038,6 +1038,16 @@ static void monitor_init_qmp_commands(void) qmp_marshal_qmp_capabilities, QCO_NO_OPTIONS); } +static bool qmp_cap_enabled (Monitor *mon,QMPCapability cap) +{ +return mon->qmp.qmp_caps[cap]; +} + +static bool qmp_oob_enabled (Monitor *mon) +{ +return qmp_cap_enabled (mon,QMP_CAPABILITY_OOB ); +} +static void qmp_caps_check (Monitor *mon,QMPCapabilityList *list,Error **errp) {
Signature · 1 line
2.13.6
RFC v4 14/27 monitor: introduce monitor_qmp_respond()
In reply to Peter XuA tiny refactoring, preparing to split the QMP dispatcher away.
--- monitor.c | 48 +++++++++++++++++++++++++++++++----------------- 1 file changed, 31 insertions(+), 17 deletions(-)
monitor.c +31 -17
@@ -3877,6 +3877,36 @@ static int monitor_can_read(void *opaque)return (mon->suspend_cnt ==0 ) ?1 :0 ; } +/* +* When rsp/err/id is passed in, the function will be responsible for +* the cleanup. +*/ +static void monitor_qmp_respond (Monitor *mon,QObject *rsp, +Error *err,QObject *id) +{ +QDict *qdict =NULL ; + +if (err) { + qdict =qdict_new (); +qdict_put_obj (qdict,"error" ,qmp_build_error_object (err)); +error_free (err); + rsp =QOBJECT (qdict); + } + +if (rsp) { +if (id) { +/* This is for the qdict below. */ +qobject_incref (id); +qdict_put_obj (qobject_to_qdict (rsp),"id" , id); + } + +monitor_json_emitter (mon, rsp); + } + +qobject_decref (id); +qobject_decref (rsp); +} +static void handle_qmp_command (JSONMessageParser *parser,GQueue *tokens,void *opaque) {
@@ -3927,24 +3957,8 @@ static void handle_qmp_command(JSONMessageParser *parser, GQueue *tokens, } err_out: -if (err) { - qdict =qdict_new (); -qdict_put_obj (qdict,"error" ,qmp_build_error_object (err)); -error_free (err); - rsp =QOBJECT (qdict); - } +monitor_qmp_respond (mon, rsp, err, id); -if (rsp) { -if (id) { -qdict_put_obj (qobject_to_qdict (rsp),"id" , id); - id =NULL ; - } - -monitor_json_emitter (mon, rsp); - } - -qobject_decref (id); -qobject_decref (rsp);qobject_decref (req); }
Signature · 1 line
2.13.6
RFC v4 15/27 monitor: let monitor_{suspend|resume} thread safe
In reply to Peter XuMonitor code now can be run in more than one thread. Let the suspend and resume code be thread safe.
--- monitor.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-)
monitor.c +3 -2
@@ -4003,7 +4003,7 @@ int monitor_suspend(Monitor *mon) {if (!mon->rs)return -ENOTTY ; - mon->suspend_cnt++; +atomic_inc (&mon->suspend_cnt);return 0 ; }
@@ -4011,8 +4011,9 @@ void monitor_resume(Monitor *mon) {if (!mon->rs)return ; -if (--mon->suspend_cnt ==0 ) +if (atomic_dec_fetch (&mon->suspend_cnt) ==0 ) {readline_show_prompt (mon->rs); + } }static QObject *get_qmp_greeting (void )
Signature · 1 line
2.13.6
Re: [Qemu-devel] [RFC v4 15/27] monitor: let monitor_{suspend|resume} thread safe
Quoted 23 lines · * Peter Xu ([email protected]) wrote:
Monitor code now can be run in more than one thread. Let the suspend and resume code be thread safe.
Reviewed-by Fam Zheng <[email protected]>Signed-off-by Peter Xu <[email protected]>--- monitor.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-)monitor.c +1
-1@@ -4003,7 +4003,7 @@ int monitor_suspend(Monitor *mon) {if (!mon->rs)return -ENOTTY ; - mon->suspend_cnt++; +atomic_inc (&mon->suspend_cnt);return 0 ; }
monitor.c void monitor_resume(Monitor *mon) · line 4019
Quoted 10 lines
monitor.c +2
-1@@ -4011,8 +4011,9 @@ void monitor_resume(Monitor *mon) {if (!mon->rs)return ; -if (--mon->suspend_cnt ==0 ) +if (atomic_dec_fetch (&mon->suspend_cnt) ==0 ) {readline_show_prompt (mon->rs); + } }static QObject *get_qmp_greeting (void )
Do you also need to do an atomic_read() in monitor_can_read? (I guess the code in monitor_event is ok because it's only the mux path, but still it's probably better to use all atomic ops on the suspend_cnt variable to be consistent).
Dave
Quoted 3 lines
Signature · 1 line
2.13.6
--
Dr. David Alan Gilbert / [email protected] / Manchester, UK
Re: [Qemu-devel] [RFC v4 15/27] monitor: let monitor_{suspend|resume} thread safe
Quoted 33 lines · Dr. David Alan Gilbert
Quoted 32 lines · * Peter Xu ([email protected]) wrote:
Monitor code now can be run in more than one thread. Let the suspend and resume code be thread safe.
Reviewed-by Fam Zheng <[email protected]>Signed-off-by Peter Xu <[email protected]>--- monitor.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-)monitor.c +3
-2@@ -4003,7 +4003,7 @@ int monitor_suspend(Monitor *mon) {if (!mon->rs)return -ENOTTY ; - mon->suspend_cnt++; +atomic_inc (&mon->suspend_cnt);return 0 ; }@@ -4011,8 +4011,9 @@ void monitor_resume(Monitor *mon) {if (!mon->rs)return ; -if (--mon->suspend_cnt ==0 ) +if (atomic_dec_fetch (&mon->suspend_cnt) ==0 ) {readline_show_prompt (mon->rs); + } }
Quoted 6 lines
monitor.c void monitor_resume(Monitor *mon) · line 4019
Quoted 1 line
monitor.c +0
-0static QObject *get_qmp_greeting (void )Do you also need to do an
atomic_read()inmonitor_can_read? (I guess the code inmonitor_eventis ok because it's only the mux path, but still it's probably better to use all atomic ops on thesuspend_cntvariable to be consistent).
Agreed.
Signature · 1 line
Peter Xu
RFC v4 16/27 monitor: separate QMP parser and dispatcher
In reply to Peter XuOriginally QMP goes throw these steps:
JSON Parser --> QMP Dispatcher --> Respond
/|\ (2) (3) |
(1) | \|/ (4)
+--------- main thread --------+This patch does this:
JSON Parser QMP Dispatcher --> Respond
/|\ | /|\ (4) |
| | (2) | (3) | (5)
(1) | +-----> | \|/
+--------- main thread <-------+So the parsing job and the dispatching job is isolated now. It gives us a chance in following up patches to totally move the parser outside.
The isloation is done using one QEMUBH. Only one dispatcher QEMUBH is used for all the monitors.
--- monitor.c | 179 ++++++++++++++++++++++++++++++++++++++++++++++++++++++-------- 1 file changed, 157 insertions(+), 22 deletions(-)
monitor.c +157 -22
@@ -168,6 +168,10 @@ typedef struct {*/ QmpCommandList *commands;bool qmp_caps[QMP_CAPABILITY__MAX ]; +/* Protects qmp request/response queue. */ +QemuMutex qmp_queue_lock; +/* Input queue that holds all the parsed QMP requests */ +GQueue *qmp_requests; } MonitorQMP;/*
@@ -213,6 +217,8 @@ struct Monitor {struct MonitorGlobal {IOThread *mon_iothread; +/* Bottom half to dispatch the requests received from IO thread */ +QEMUBH *qmp_dispatcher_bh; };static struct MonitorGlobal mon_global;
@@ -582,11 +588,13 @@ static void monitor_data_init(Monitor *mon, bool skip_flush, {memset (mon,0 ,sizeof (Monitor));qemu_mutex_init (&mon->out_lock); +qemu_mutex_init (&mon->qmp.qmp_queue_lock); mon->outbuf =qstring_new ();/* Use *mon_cmds by default. */ mon->cmd_table = mon_cmds; mon->skip_flush = skip_flush; mon->use_io_thr = use_io_thr; + mon->qmp.qmp_requests =g_queue_new (); }static void monitor_data_destroy (Monitor *mon)
@@ -599,6 +607,8 @@ static void monitor_data_destroy(Monitor *mon)g_free (mon->rs);QDECREF (mon->outbuf);qemu_mutex_destroy (&mon->out_lock); +qemu_mutex_destroy (&mon->qmp.qmp_queue_lock); +g_queue_free (mon->qmp.qmp_requests); } char *qmp_human_monitor_command(const char *command_line, bool has_cpu_index,
@@ -3907,29 +3917,31 @@ static void monitor_qmp_respond(Monitor *mon, QObject *rsp,qobject_decref (rsp); } -static void handle_qmp_command (JSONMessageParser *parser,GQueue *tokens, -void *opaque) +struct QMPRequest { +/* Owner of the request */ +Monitor *mon; +/* "id" field of the request */ +QObject *id; +/* Request object to be handled */ +QObject *req; +}; +typedef struct QMPRequest QMPRequest ; + +/* +* Dispatch one single QMP request. The function will free the req_obj +* and objects inside it before return. +*/ +static void monitor_qmp_dispatch_one (QMPRequest *req_obj) { -QObject *req, *rsp =NULL , *id =NULL ; +Monitor *mon, *old_mon; +QObject *req, *rsp =NULL , *id;QDict *qdict =NULL ; -Monitor *mon = opaque, *old_mon; -Error *err =NULL ; - req =json_parser_parse_err (tokens,NULL , &err); -if (!req && !err) { -/* json_parser_parse_err() sucks: can fail without setting @err */ -error_setg (&err,QERR_JSON_PARSING ); - } -if (err) { - goto err_out; - } + req = req_obj->req; + mon = req_obj->mon; + id = req_obj->id; - qdict =qobject_to_qdict (req); -if (qdict) { - id =qdict_get (qdict,"id" ); -qobject_incref (id); -qdict_del (qdict,"id" ); - }/* else will fail qmp_dispatch() */ +g_free (req_obj);if (trace_event_get_state_backends (TRACE_HANDLE_QMP_COMMAND )) {QString *req_json =qobject_to_json (req);
@@ -3940,7 +3952,7 @@ static void handle_qmp_command(JSONMessageParser *parser, GQueue *tokens, old_mon = cur_mon; cur_mon = mon; - rsp =qmp_dispatch (cur_mon->qmp.commands, req); + rsp =qmp_dispatch (mon->qmp.commands, req); cur_mon = old_mon;
@@ -3956,12 +3968,122 @@ static void handle_qmp_command(JSONMessageParser *parser, GQueue *tokens, } } -err_out: -monitor_qmp_respond (mon, rsp, err, id); +/* Respond if necessary */ +monitor_qmp_respond (mon, rsp,NULL , id); + +/* This pairs with the monitor_suspend() in handle_qmp_command(). */ +if (!qmp_oob_enabled (mon)) { +monitor_resume (mon); + }qobject_decref (req); } +/* +* Pop one QMP request from monitor queues, return NULL if not found. +* We are using round-robin fasion to pop the request, to avoid +* processing command only on a very busy monitor. To achieve that, +* when we processed one request on specific monitor, we put that +* monitor to the end of mon_list queue. +*/ +static QMPRequest *monitor_qmp_requests_pop_one (void ) +{ +QMPRequest *req_obj =NULL ; +Monitor *mon; + +qemu_mutex_lock (&monitor_lock); + + QTAILQ_FOREACH(mon, &mon_list, entry) { +qemu_mutex_lock (&mon->qmp.qmp_queue_lock); + req_obj =g_queue_pop_head (mon->qmp.qmp_requests); +qemu_mutex_unlock (&mon->qmp.qmp_queue_lock); +if (req_obj) { +break ; + } + } + +if (req_obj) { +/* +* We found one request on the monitor. Degrade this monitor's +* priority to lowest by re-inserting it to end of queue. +*/ +QTAILQ_REMOVE (&mon_list, mon, entry); +QTAILQ_INSERT_TAIL (&mon_list, mon, entry); + } + +qemu_mutex_unlock (&monitor_lock); + +return req_obj; +} + +static void monitor_qmp_bh_dispatcher (void *data) +{ +QMPRequest *req_obj; + +while (true) { + req_obj =monitor_qmp_requests_pop_one (); +if (!req_obj) { +break ; + } +monitor_qmp_dispatch_one (req_obj); + } +} + +static void handle_qmp_command (JSONMessageParser *parser,GQueue *tokens, +void *opaque) +{ +QObject *req, *id =NULL ; +QDict *qdict =NULL ; +Monitor *mon = opaque; +Error *err =NULL ; +QMPRequest *req_obj; + + req =json_parser_parse_err (tokens,NULL , &err); +if (!req && !err) { +/* json_parser_parse_err() sucks: can fail without setting @err */ +error_setg (&err,QERR_JSON_PARSING ); + } +if (err) { +monitor_qmp_respond (mon,NULL , err,NULL ); +qobject_decref (req); +return ; + } + + qdict =qobject_to_qdict (req); +if (qdict) { + id =qdict_get (qdict,"id" ); +qobject_incref (id); +qdict_del (qdict,"id" ); + }/* else will fail qmp_dispatch() */ + + req_obj =g_new0 (QMPRequest,1 ); + req_obj->mon = mon; + req_obj->id = id; + req_obj->req = req; + +/* +* Put the request to the end of queue so that requests will be +* handled in time order. Ownership for req_obj, req, id, +* etc. will be delivered to the handler side. +*/ +qemu_mutex_lock (&mon->qmp.qmp_queue_lock); +g_queue_push_tail (mon->qmp.qmp_requests, req_obj); +qemu_mutex_unlock (&mon->qmp.qmp_queue_lock); + +/* Kick the dispatcher routine */ +qemu_bh_schedule (mon_global.qmp_dispatcher_bh); + +/* +* If OOB is not enabled on current monitor, we'll emulate the old +* behavior that we won't process current monitor any more until +* it is responded. This helps make sure that as long as OOB is +* not enabled, the server will never drop any command. +*/ +if (!qmp_oob_enabled (mon)) { +monitor_suspend (mon); + } +} +static void monitor_qmp_read (void *opaque,const uint8_t *buf,int size) {Monitor *mon = opaque;
@@ -4144,6 +4266,15 @@ static void monitor_iothread_init(void) { mon_global.mon_iothread =iothread_create ("monitor_iothread" , &error_abort); + +/* +* This MUST be on main loop thread since we have commands that +* have assumption to be run on main loop thread (Yeah, we'd +* better remove this assumption in the future). +*/ + mon_global.qmp_dispatcher_bh =aio_bh_new (qemu_get_aio_context (), + monitor_qmp_bh_dispatcher, +NULL ); }void monitor_init_globals (void )
@@ -4264,6 +4395,10 @@ void monitor_cleanup(void) }qemu_mutex_unlock (&monitor_lock); +/* QEMUBHs needs to be deleted before destroying the IOThread. */ +qemu_bh_delete (mon_global.qmp_dispatcher_bh); + mon_global.qmp_dispatcher_bh =NULL ; +iothread_destroy (mon_global.mon_iothread); mon_global.mon_iothread =NULL ; }
Signature · 1 line
2.13.6
RFC v4 17/27 qmp: add new event "request-dropped"
In reply to Peter XuThis event will be emitted if one QMP request is dropped. Along, declare an enum for the reasons.
--- qapi-schema.json | 34 ++++++++++++++++++++++++++++++++++ 1 file changed, 34 insertions(+)
qapi-schema.json +34 -0
@@ -3222,3 +3222,37 @@ # Since: 2.11 ## { 'command': 'watchdog-set-action', 'data' : {'action': 'WatchdogAction'} } + +## +# @RequestDropReason: +# +# Reasons that caused one command to be dropped. +# +# @queue-full: the queue of request is full. +# +# Since: 2.12 +## +{ 'enum': 'RequestDropReason', + 'data': [ 'queue-full' ] } + +## +# @REQUEST_DROPPED: +# +# Emitted when one QMP request is dropped due to some reason. +# REQUEST_DROPPED is only emitted when the oob capability is enabled. +# +# @id: The dropped command's "id" field. +# +# @reason: The reason why the request is dropped. +# +# Since: 2.12 +# +# Example: +# +# { "event": "REQUEST_DROPPED", +# "data": {"result": {"id": "libvirt-102", +# "reason": "queue-full" } } } +# +## +{ 'event': 'REQUEST_DROPPED' , + 'data': { 'id': 'any', 'reason': 'RequestDropReason' } }
Signature · 1 line
2.13.6
RFC v4 18/27 monitor: send event when request queue full
In reply to Peter XuSet maximum QMP request queue length to 8. If queue full, instead of queue the command, we directly return a "request-dropped" event, telling client that specific command is dropped.
Note that this flow control mechanism is only valid if OOB is enabled. If it's not, the effective queue length will always be 1, which strictly follows original behavior of QMP command handling (which never drop messages).
--- monitor.c | 15 +++++++++++++++ 1 file changed, 15 insertions(+)
monitor.c +15 -0
@@ -4029,6 +4029,8 @@ static void monitor_qmp_bh_dispatcher(void *data) } } +#define QMP_REQ_QUEUE_LEN_MAX (8) +static void handle_qmp_command (JSONMessageParser *parser,GQueue *tokens,void *opaque) {
@@ -4061,6 +4063,19 @@ static void handle_qmp_command(JSONMessageParser *parser, GQueue *tokens, req_obj->id = id; req_obj->req = req; +if (qmp_oob_enabled (mon)) { +/* Drop the request if queue is full. */ +if (mon->qmp.qmp_requests->length >=QMP_REQ_QUEUE_LEN_MAX ) { +qapi_event_send_request_dropped (id, +REQUEST_DROP_REASON_QUEUE_FULL , +NULL ); +qobject_decref (id); +qobject_decref (req); +g_free (req_obj); +return ; + } + } +/* * Put the request to the end of queue so that requests will be * handled in time order. Ownership for req_obj, req, id,
Signature · 1 line
2.13.6
RFC v4 19/27 qapi: introduce new cmd option "allow-oob"
In reply to Peter XuHere "oob" stands for "Out-Of-Band". When "allow-oob" is set, it means the command allows out-of-band execution.
The "oob" idea is proposed by Markus Armbruster in following thread:
https://lists.gnu.org/archive/html/qemu-devel/2017-09/msg02057.html
This new "allow-oob" boolean will be exposed by "query-qmp-schema" as well for command entries, so that QMP clients can know which command can be used as out-of-band calls. For example the command "migrate" originally looks like:
{"name": "migrate", "ret-type": "17", "meta-type": "command",
"arg-type": "86"}
And it'll be changed into:
{"name": "migrate", "ret-type": "17", "allow-oob": false,
"meta-type": "command", "arg-type": "86"}
This patch only provides the QMP interface level changes. It does not contains the real out-of-band execution implementation yet.
--- include/qapi/qmp/dispatch.h | 1 + qapi/introspect.json | 6 +++++- scripts/qapi-commands.py | 19 ++++++++++++++----- scripts/qapi-introspect.py | 10 ++++++++-- scripts/qapi.py | 15 ++++++++++----- scripts/qapi2texi.py | 2 +- tests/qapi-schema/test-qapi.py | 2 +- 7 files changed, 40 insertions(+), 15 deletions(-)
include/qapi/qmp/dispatch.h +1 -0
@@ -23,6 +23,7 @@ typedef enum QmpCommandOptions {QCO_NO_OPTIONS =0x0 ,QCO_NO_SUCCESS_RESP =0x1 , +QCO_ALLOW_OOB =0x2 , } QmpCommandOptions; typedef struct QmpCommand
qapi/introspect.json +5 -1
@@ -259,12 +259,16 @@ # # @ret-type: the name of the command's result type. # +# @allow-oob: whether the command allows out-of-band execution. +# (Since: 2.11) +# # TODO: @success-response (currently irrelevant, because it's QGA, not QMP) # # Since: 2.5 ## { 'struct': 'SchemaInfoCommand', - 'data': { 'arg-type': 'str', 'ret-type': 'str' } } + 'data': { 'arg-type': 'str', 'ret-type': 'str', + 'allow-oob': 'bool' } } ## # @SchemaInfoEvent:
scripts/qapi-commands.py +14 -5
@@ -192,10 +192,18 @@ out: return ret -def gen_register_command(name, success_response): - options = 'QCO_NO_OPTIONS' +def gen_register_command(name, success_response, allow_oob): + options = [] + if not success_response: - options = 'QCO_NO_SUCCESS_RESP' + options += ['QCO_NO_SUCCESS_RESP'] + if allow_oob: + options += ['QCO_ALLOW_OOB'] + + if not options: + options = ['QCO_NO_OPTIONS'] + + options = " | ".join(options) ret = mcgen(''' qmp_register_command(cmds, "%(name)s",
@@ -241,7 +249,7 @@ class QAPISchemaGenCommandVisitor(QAPISchemaVisitor): self._visited_ret_types = None def visit_command(self, name, info, arg_type, ret_type, - gen, success_response, boxed): + gen, success_response, boxed, allow_oob): if not gen: return self.decl += gen_command_decl(name, arg_type, boxed, ret_type)
@@ -250,7 +258,8 @@ class QAPISchemaGenCommandVisitor(QAPISchemaVisitor): self.defn += gen_marshal_output(ret_type) self.decl += gen_marshal_decl(name) self.defn += gen_marshal(name, arg_type, boxed, ret_type) - self._regy += gen_register_command(name, success_response) + self._regy += gen_register_command(name, success_response, + allow_oob) (input_file, output_dir, do_c, do_h, prefix, opts) = parse_command_line()
scripts/qapi-introspect.py +8 -2
@@ -28,6 +28,11 @@ def to_json(obj, level=0): to_json(obj[key], level + 1)) for key in sorted(obj.keys())] ret = '{' + ', '.join(elts) + '}' + elif isinstance(obj, bool): + if obj: + ret = 'true' + else: + ret = 'false' else: assert False # not implemented if level == 1:
@@ -154,12 +159,13 @@ const char %(c_name)s[] = %(c_string)s; for m in variants.variants]}) def visit_command(self, name, info, arg_type, ret_type, - gen, success_response, boxed): + gen, success_response, boxed, allow_oob): arg_type = arg_type or self._schema.the_empty_object_type ret_type = ret_type or self._schema.the_empty_object_type self._gen_json(name, 'command', {'arg-type': self._use_type(arg_type), - 'ret-type': self._use_type(ret_type)}) + 'ret-type': self._use_type(ret_type), + 'allow-oob': allow_oob}) def visit_event(self, name, info, arg_type, boxed): arg_type = arg_type or self._schema.the_empty_object_type
scripts/qapi.py +10 -5
@@ -920,7 +920,8 @@ def check_exprs(exprs): elif 'command' in expr: meta = 'command' check_keys(expr_elem, 'command', [], - ['data', 'returns', 'gen', 'success-response', 'boxed']) + ['data', 'returns', 'gen', 'success-response', + 'boxed', 'allow-oob']) elif 'event' in expr: meta = 'event' check_keys(expr_elem, 'event', [], ['data', 'boxed'])
@@ -1031,7 +1032,7 @@ class QAPISchemaVisitor(object): pass def visit_command(self, name, info, arg_type, ret_type, - gen, success_response, boxed): + gen, success_response, boxed, allow_oob): pass def visit_event(self, name, info, arg_type, boxed):
@@ -1398,7 +1399,7 @@ class QAPISchemaAlternateType(QAPISchemaType): class QAPISchemaCommand(QAPISchemaEntity): def __init__(self, name, info, doc, arg_type, ret_type, - gen, success_response, boxed): + gen, success_response, boxed, allow_oob): QAPISchemaEntity.__init__(self, name, info, doc) assert not arg_type or isinstance(arg_type, str) assert not ret_type or isinstance(ret_type, str)
@@ -1409,6 +1410,7 @@ class QAPISchemaCommand(QAPISchemaEntity): self.gen = gen self.success_response = success_response self.boxed = boxed + self.allow_oob = allow_oob def check(self, schema): if self._arg_type_name:
@@ -1432,7 +1434,8 @@ class QAPISchemaCommand(QAPISchemaEntity): def visit(self, visitor): visitor.visit_command(self.name, self.info, self.arg_type, self.ret_type, - self.gen, self.success_response, self.boxed) + self.gen, self.success_response, + self.boxed, self.allow_oob) class QAPISchemaEvent(QAPISchemaEntity):
@@ -1640,6 +1643,7 @@ class QAPISchema(object): gen = expr.get('gen', True) success_response = expr.get('success-response', True) boxed = expr.get('boxed', False) + allow_oob = expr.get('allow-oob', False) if isinstance(data, OrderedDict): data = self._make_implicit_object_type( name, info, doc, 'arg', self._make_members(data, info))
@@ -1647,7 +1651,8 @@ class QAPISchema(object): assert len(rets) == 1 rets = self._make_array_type(rets[0], info) self._def_entity(QAPISchemaCommand(name, info, doc, data, rets, - gen, success_response, boxed)) + gen, success_response, + boxed, allow_oob)) def _def_event(self, expr, info, doc): name = expr['event']
scripts/qapi2texi.py +1 -1
@@ -236,7 +236,7 @@ class QAPISchemaGenDocVisitor(qapi.QAPISchemaVisitor): body=texi_entity(doc, 'Members')) def visit_command(self, name, info, arg_type, ret_type, - gen, success_response, boxed): + gen, success_response, boxed, allow_oob): doc = self.cur_doc if self.out: self.out += '\n'
tests/qapi-schema/test-qapi.py +1 -1
@@ -36,7 +36,7 @@ class QAPISchemaTestVisitor(QAPISchemaVisitor): self._print_variants(variants) def visit_command(self, name, info, arg_type, ret_type, - gen, success_response, boxed): + gen, success_response, boxed, allow_oob): print 'command %s %s -> %s' % \ (name, arg_type and arg_type.name, ret_type and ret_type.name) print ' gen=%s success_response=%s boxed=%s' % \
Signature · 1 line
2.13.6
RFC v4 20/27 qmp: support out-of-band (oob) execution
In reply to Peter XuHaving "allow-oob" to true for a command does not mean that this command will always be run in out-of-band mode. The out-of-band quick path will only be executed if we specify the extra "run-oob" flag when sending the QMP request:
{ "execute": "command-that-allows-oob",
"arguments": { ... },
"control": { "run-oob": true } }The "control" key is introduced to store this extra flag. "control" field is used to store arguments that are shared by all the commands, rather than command specific arguments. Let "run-oob" be the first.
--- include/qapi/qmp/dispatch.h | 1 + monitor.c | 24 ++++++++++++++++++++++++ qapi/qmp-dispatch.c | 39 +++++++++++++++++++++++++++++++++++++++ trace-events | 2 ++ 4 files changed, 66 insertions(+)
include/qapi/qmp/dispatch.h +1 -0
@@ -49,6 +49,7 @@ bool qmp_command_is_enabled(const QmpCommand *cmd);const char *qmp_command_name (const QmpCommand *cmd);bool qmp_has_success_response (const QmpCommand *cmd);QObject *qmp_build_error_object (Error *err); +bool qmp_is_oob (const QObject *request);typedef void (*qmp_cmd_callback_fn )(QmpCommand *cmd,void *opaque);
monitor.c +24 -0
@@ -4025,6 +4025,7 @@ static void monitor_qmp_bh_dispatcher(void *data)if (!req_obj) {break ; } +trace_monitor_qmp_cmd_in_band (qobject_get_try_str (req_obj->id));monitor_qmp_dispatch_one (req_obj); } }
@@ -4051,9 +4052,25 @@ static void handle_qmp_command(JSONMessageParser *parser, GQueue *tokens,return ; } +if (!qmp_oob_enabled (mon) &&qmp_is_oob (req)) { +error_setg (&err,"Out-Of-Band is only allowed " +"when OOB is enabled." ); +monitor_qmp_respond (mon,NULL , err,NULL ); +qobject_decref (req); +return ; + } + qdict =qobject_to_qdict (req);if (qdict) { id =qdict_get (qdict,"id" ); +/* When OOB is enabled, the "id" field is mandatory. */ +if (qmp_oob_enabled (mon) && !id) { +error_setg (&err,"Out-Of-Band capability requires that " +"every command contains an 'id' field." ); +monitor_qmp_respond (mon,NULL , err,NULL ); +qobject_decref (req); +return ; + }qobject_incref (id);qdict_del (qdict,"id" ); }/* else will fail qmp_dispatch() */
@@ -4064,6 +4081,13 @@ static void handle_qmp_command(JSONMessageParser *parser, GQueue *tokens, req_obj->req = req;if (qmp_oob_enabled (mon)) { +if (qmp_is_oob (req)) { +/* Out-Of-Band (OOB) requests are executed directly in parser. */ +trace_monitor_qmp_cmd_out_of_band (qobject_get_try_str (req_obj->id)); +monitor_qmp_dispatch_one (req_obj); +return ; + } +/* Drop the request if queue is full. */ if (mon->qmp.qmp_requests->length >=QMP_REQ_QUEUE_LEN_MAX ) { qapi_event_send_request_dropped(id,
qapi/qmp-dispatch.c +39 -0
@@ -52,6 +52,12 @@ static QDict *qmp_dispatch_check_obj(const QObject *request, Error **errp) "QMP input member 'arguments' must be an object");return NULL ; } + }else if (!strcmp (arg_name,"control" )) { +if (qobject_type (arg_obj) !=QTYPE_QDICT ) { +error_setg (errp, +"QMP input member 'control' must be a dict" ); +return NULL ; + } }else {error_setg (errp,"QMP input member '%s' is unexpected" , arg_name);
@@ -94,6 +100,11 @@ static QObject *do_qmp_dispatch(QmpCommandList *cmds, QObject *request,return NULL ; } +if (qmp_is_oob (request) && !(cmd->options &QCO_ALLOW_OOB )) { +error_setg (errp,"The command %s does not support OOB" , command); +return NULL ; + } +if (!qdict_haskey (dict,"arguments" )) { args =qdict_new (); }else {
@@ -122,6 +133,34 @@ QObject *qmp_build_error_object(Error *err) error_get_pretty(err)); } +/* +* Detect whether a request should be run out-of-band, by quickly +* peeking at whether we have: { "control": { "run-oob": True } }. By +* default commands are run in-band. +*/ +bool qmp_is_oob (const QObject *request) +{ +QDict *dict; +QBool *bool_obj; + + dict =qobject_to_qdict (request); +if (!dict) { +return false; + } + + dict =qdict_get_qdict (dict,"control" ); +if (!dict) { +return false; + } + + bool_obj =qobject_to_qbool (qdict_get (dict,"run-oob" )); +if (!bool_obj) { +return false; + } + +return qbool_get_bool (bool_obj); +} +QObject *qmp_dispatch (QmpCommandList *cmds,QObject *request) {Error *err =NULL ;
trace-events +2 -0
@@ -47,6 +47,8 @@ monitor_protocol_event_emit(uint32_t event, void *data) "event=%d data=%p" monitor_protocol_event_queue(uint32_t event, void *qdict, uint64_t rate) "event=%d data=%p rate=%" PRId64 handle_hmp_command(void *mon, const char *cmdline) "mon %p cmdline: %s" handle_qmp_command(void *mon, const char *req) "mon %p req: %s" +monitor_qmp_cmd_in_band(const char *id) "%s" +monitor_qmp_cmd_out_of_band(const char *id) "%s" # dma-helpers.c dma_blk_io(void *dbs, void *bs, int64_t offset, bool to_dev) "dbs=%p bs=%p offset=%" PRId64 " to_dev=%d"
Signature · 1 line
2.13.6
RFC v4 21/27 qmp: let migrate-incoming allow out-of-band
In reply to Peter XuSo it can get rid of being run on main thread.
--- qapi/migration.json | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-)
qapi/migration.json +2 -1
@@ -1063,7 +1063,8 @@ # <- { "return": {} } # ## -{ 'command': 'migrate-incoming', 'data': {'uri': 'str' } } +{ 'command': 'migrate-incoming', 'data': {'uri': 'str' }, + 'allow-oob': true } ## # @xen-save-devices-state:
Signature · 1 line
2.13.6
Re: [Qemu-devel] [RFC v4 21/27] qmp: let migrate-incoming allow out-of-band
Quoted 3 lines · * Peter Xu ([email protected]) wrote:
So it can get rid of being run on main thread.
Signed-off-by Peter Xu <[email protected]>
Last time I asked if you were sure that we didn't do locking, and you explained that we end up just setting up a callback that happens in the mainloop, and this shouldn't take a lock. I confirmed this by:
running with -incoming defer
breakpointing in hmp_migrate_incoming
doing migrate_incoming tcp:0:4444
once I hit that breakpointing adding two more breakpoints:
a) qemu_mutex_lock_iothread
b) the end of hmp's handle_hmp_command
and indeed it hit the end of handle_hmp_command without
having hit the qemu_mutex_lock_iothread; so initially that looks ok.
But then I added a break on pthread_mutex_lock, and I've got this set caused by qemu_start_incoming_migration sending a MIGRATION_STATUS_SETUP event:
#1 0x0000555555ba6eba in qemu_mutex_lock (mutex=mutex@entry=0x5555563f9ba0 <monitor_lock>)
at /home/dgilbert/git/qemu/util/qemu-thread-posix.c:65
#2 0x00005555557f01c1 in monitor_qapi_event_queue (event=QAPI_EVENT_MIGRATION, qdict=0x555557d93c00, errp=<optimized out>) at /home/dgilbert/git/qemu/monitor.c:442
440 trace_monitor_protocol_event_queue(event, qdict, evconf->rate);
441
442 qemu_mutex_lock(&monitor_lock);
443
#3 0x0000555555b92722 in qapi_event_send_migration (status=status@entry=MIGRATION_STATUS_SETUP, errp=0x555556859320 <error_abort>) at qapi-event.c:661 #4 0x0000555555a6159f in qemu_start_incoming_migration (uri=0x555557693f30 "tcp:0:4444", errp=0x7fffffffc700)
at /home/dgilbert/git/qemu/migration/migration.c:253
#5 0x0000555555a641c5 in qmp_migrate_incoming (uri=0x555557693f30 "tcp:0:4444", errp=0x7fffffffc730)
at /home/dgilbert/git/qemu/migration/migration.c:1321
is there anything which protects us there?
Dave
Quoted 21 lines
--- qapi/migration.json | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-)qapi/migration.json +2
-1@@ -1063,7 +1063,8 @@ # <- { "return": {} } # ## -{ 'command': 'migrate-incoming', 'data': {'uri': 'str' } } +{ 'command': 'migrate-incoming', 'data': {'uri': 'str' }, + 'allow-oob': true } ## # @xen-save-devices-state:Signature · 1 line
2.13.6
--
Dr. David Alan Gilbert / [email protected] / Manchester, UK
Re: [Qemu-devel] [RFC v4 21/27] qmp: let migrate-incoming allow out-of-band
Quoted 17 lines · Dr. David Alan Gilbert
Quoted 3 lines · * Peter Xu ([email protected]) wrote:
So it can get rid of being run on main thread.
Signed-off-by Peter Xu <[email protected]>Last time I asked if you were sure that we didn't do locking, and you explained that we end up just setting up a callback that happens in the mainloop, and this shouldn't take a lock. I confirmed this by:
running with -incoming defer
breakpointing inhmp_migrate_incoming
doingmigrate_incomingtcp:0:4444
once I hit that breakpointing adding two more breakpoints:
a)qemu_mutex_lock_iothread
b) the end of hmp'shandle_hmp_command
Quoted 3 lines
and indeed it hit the end of
handle_hmp_commandwithout
having hit theqemu_mutex_lock_iothread; so initially that looks ok.
I am not sure I fully understand the test above - I think it was trying to verify the whole OOB thing running without BQL? If so, there are possibly two things missing:
Firstly, qemu_mutex_lock_iothread() is actually called before we call hmp_migrate_incoming(). To verify it is simple: just break at entry of hmp_migrate_incoming() and do "p iothread_locked", it'll be true (I would always prefer printing that global variable to know whether current thread is in a BQL section).
Secondly, HMP will still always take the BQL; this patch only enables OOB for QMP command "migrate-incoming" rather than the HMP command. So IMHO what we need to test is QMP command, rather than this HMP one.
To test that QMP command, it's still not that easy (actually awkward). We need to first enable "OOB" when doing handshake for QMP:
{"execute": "qmp_capabilities", "arguments": { "enable": [ "oob" ] } }
Then, we need to send the command with proper "id"/"control" field:
{ "execute": "migrate-incoming",
"arguments": { "uri": "tcp:localhost:1234" },
"control": { "run-oob": true },
"id": "test-command" }Note that here "id" field will be a must now since OOB requires that, meanwhile the "control" field is a must too to make sure that is run in OOB format (otherwise this command will still take BQL and run as usual). So if you see we do have a lot of protection to make sure we only run OOB only if we really wanted to... otherwise we'll always run in compatible and old way.
This time if we break at qmp_migrate_incoming() and then do "p iothread_locked", we should see a false here.
Quoted 14 lines
But then I added a break on
pthread_mutex_lock, and I've got this set caused byqemu_start_incoming_migrationsending aMIGRATION_STATUS_SETUPevent:#1
0x0000555555ba6ebainqemu_mutex_lock(mutex=mutex@entry=0x5555563f9ba0 <monitor_lock>)
at/home/dgilbert/git/qemu/util/qemu-thread-posix.c:65
#20x00005555557f01c1inmonitor_qapi_event_queue(event=QAPI_EVENT_MIGRATION, qdict=0x555557d93c00, errp=<optimized out>) at/home/dgilbert/git/qemu/monitor.c:442440
trace_monitor_protocol_event_queue(event, qdict, evconf->rate);
441
442qemu_mutex_lock(&monitor_lock);
443
Quoted 7 lines
#3
0x0000555555b92722inqapi_event_send_migration(status=status@entry=MIGRATION_STATUS_SETUP, errp=0x555556859320 <error_abort>) at qapi-event.c:661 #40x0000555555a6159finqemu_start_incoming_migration(uri=0x555557693f30 "tcp:0:4444", errp=0x7fffffffc700)
at/home/dgilbert/git/qemu/migration/migration.c:253
#50x0000555555a641c5inqmp_migrate_incoming(uri=0x555557693f30 "tcp:0:4444", errp=0x7fffffffc730)
at/home/dgilbert/git/qemu/migration/migration.c:1321is there anything which protects us there?
IIUC you mean what if we e.g. page fault during taking the monitor_lock? IMHO it just can't happen - monitor_lock is really used in limited places and during those critical sections there is no guest memory access at all (which only protects the monitor logic itself AFAICT).
Thanks,
Quoted 26 lines
Dave
Quoted 21 lines
--- qapi/migration.json | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-)qapi/migration.json +2
-1@@ -1063,7 +1063,8 @@ # <- { "return": {} } # ## -{ 'command': 'migrate-incoming', 'data': {'uri': 'str' } } +{ 'command': 'migrate-incoming', 'data': {'uri': 'str' }, + 'allow-oob': true } ## # @xen-save-devices-state:Signature · 1 line
2.13.6--
Dr. David Alan Gilbert / [email protected] / Manchester, UK
Signature · 1 line
Peter Xu
Dr. David Alan Gilbert
Reviewed-byRe: [Qemu-devel] [RFC v4 21/27] qmp: let migrate-incoming allow out-of-band
Quoted 26 lines · * Peter Xu ([email protected]) wrote:
Quoted 17 lines · Dr. David Alan Gilbert
Quoted 3 lines · * Peter Xu ([email protected]) wrote:
So it can get rid of being run on main thread.
Signed-off-by Peter Xu <[email protected]>Last time I asked if you were sure that we didn't do locking, and you explained that we end up just setting up a callback that happens in the mainloop, and this shouldn't take a lock. I confirmed this by:
running with -incoming defer
breakpointing inhmp_migrate_incoming
doingmigrate_incomingtcp:0:4444
once I hit that breakpointing adding two more breakpoints:
a)qemu_mutex_lock_iothread
b) the end of hmp'shandle_hmp_commandQuoted 3 lines
and indeed it hit the end of
handle_hmp_commandwithout
having hit theqemu_mutex_lock_iothread; so initially that looks ok.I am not sure I fully understand the test above - I think it was trying to verify the whole OOB thing running without BQL? If so, there are possibly two things missing:
Quoted 6 lines
Firstly,
qemu_mutex_lock_iothread()is actually called before we callhmp_migrate_incoming(). To verify it is simple: just break at entry ofhmp_migrate_incoming()and do "piothread_locked", it'll be true (I would always prefer printing that global variable to know whether current thread is in a BQL section).
Yes, that's a good point - I was really trying to just follow through qmp_migrate_incoming a bit, but you've got a point that it was really the wrong way to look at it.
Quoted 45 lines
OOB for QMP command "migrate-incoming" rather than the HMP command. So IMHO what we need to test is QMP command, rather than this HMP one.
To test that QMP command, it's still not that easy (actually awkward). We need to first enable "OOB" when doing handshake for QMP:
{"execute": "
qmp_capabilities", "arguments": { "enable": [ "oob" ] } }Then, we need to send the command with proper "id"/"control" field:
{ "execute": "migrate-incoming",
"arguments": { "uri": "tcp:localhost:1234" }, "control": { "run-oob": true }, "id": "test-command" }Note that here "id" field will be a must now since OOB requires that, meanwhile the "control" field is a must too to make sure that is run in OOB format (otherwise this command will still take BQL and run as usual). So if you see we do have a lot of protection to make sure we only run OOB only if we really wanted to... otherwise we'll always run in compatible and old way.
This time if we break at
qmp_migrate_incoming()and then do "piothread_locked", we should see a false here.Quoted 20 lines
But then I added a break on
pthread_mutex_lock, and I've got this set caused byqemu_start_incoming_migrationsending aMIGRATION_STATUS_SETUPevent:#1
0x0000555555ba6ebainqemu_mutex_lock(mutex=mutex@entry=0x5555563f9ba0 <monitor_lock>)
at/home/dgilbert/git/qemu/util/qemu-thread-posix.c:65
#20x00005555557f01c1inmonitor_qapi_event_queue(event=QAPI_EVENT_MIGRATION, qdict=0x555557d93c00, errp=<optimized out>) at/home/dgilbert/git/qemu/monitor.c:442440
trace_monitor_protocol_event_queue(event, qdict, evconf->rate);
441
442qemu_mutex_lock(&monitor_lock);
443#3
0x0000555555b92722inqapi_event_send_migration(status=status@entry=MIGRATION_STATUS_SETUP, errp=0x555556859320 <error_abort>) at qapi-event.c:661 #40x0000555555a6159finqemu_start_incoming_migration(uri=0x555557693f30 "tcp:0:4444", errp=0x7fffffffc700)
at/home/dgilbert/git/qemu/migration/migration.c:253
#50x0000555555a641c5inqmp_migrate_incoming(uri=0x555557693f30 "tcp:0:4444", errp=0x7fffffffc730)
at/home/dgilbert/git/qemu/migration/migration.c:1321
Quoted 7 lines
Quoted 1 line
is there anything which protects us there?
IIUC you mean what if we e.g. page fault during taking the
monitor_lock? IMHO it just can't happen -monitor_lockis really used in limited places and during those critical sections there is no guest memory access at all (which only protects the monitor logic itself AFAICT).
OK, so we should document somewhere which locks it's OK to take in an OOB command, and then make sure that for each of those locks we add a note saying that anyone taking them must be careful.
We should also add a note above teh qmp_migrate_incoming that it's an OOB command and to take care.
However, since you've convinced me it's OK:
Quoted 21 lines
Thanks,
Quoted 19 lines
Dave
Quoted 16 lines
--- qapi/migration.json | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-)qapi/migration.json +2
-1@@ -1063,7 +1063,8 @@ # <- { "return": {} } # ## -{ 'command': 'migrate-incoming', 'data': {'uri': 'str' } } +{ 'command': 'migrate-incoming', 'data': {'uri': 'str' }, + 'allow-oob': true }
Quoted 10 lines
Quoted 7 lines
Quoted 5 lines
qapi/migration.json +0
-0## # @xen-save-devices-state:Signature · 1 line
2.13.6--
Dr. David Alan Gilbert / [email protected] / Manchester, UKSignature · 1 line
Peter Xu
--
Dr. David Alan Gilbert / [email protected] / Manchester, UK
Re: [Qemu-devel] [RFC v4 21/27] qmp: let migrate-incoming allow out-of-band
On Mon, Nov 27, 2017 at 10:44:26AM +0000, Dr. David Alan Gilbert wrote:
[...]
Quoted 28 lines
Quoted 20 lines
Quoted 20 lines
But then I added a break on
pthread_mutex_lock, and I've got this set caused byqemu_start_incoming_migrationsending aMIGRATION_STATUS_SETUPevent:#1
0x0000555555ba6ebainqemu_mutex_lock(mutex=mutex@entry=0x5555563f9ba0 <monitor_lock>)
at/home/dgilbert/git/qemu/util/qemu-thread-posix.c:65
#20x00005555557f01c1inmonitor_qapi_event_queue(event=QAPI_EVENT_MIGRATION, qdict=0x555557d93c00, errp=<optimized out>) at/home/dgilbert/git/qemu/monitor.c:442440
trace_monitor_protocol_event_queue(event, qdict, evconf->rate);
441
442qemu_mutex_lock(&monitor_lock);
443#3
0x0000555555b92722inqapi_event_send_migration(status=status@entry=MIGRATION_STATUS_SETUP, errp=0x555556859320 <error_abort>) at qapi-event.c:661 #40x0000555555a6159finqemu_start_incoming_migration(uri=0x555557693f30 "tcp:0:4444", errp=0x7fffffffc700)
at/home/dgilbert/git/qemu/migration/migration.c:253
#50x0000555555a641c5inqmp_migrate_incoming(uri=0x555557693f30 "tcp:0:4444", errp=0x7fffffffc730)
at/home/dgilbert/git/qemu/migration/migration.c:1321Quoted 7 lines
Quoted 1 line
is there anything which protects us there?
IIUC you mean what if we e.g. page fault during taking the
monitor_lock? IMHO it just can't happen -monitor_lockis really used in limited places and during those critical sections there is no guest memory access at all (which only protects the monitor logic itself AFAICT).
Quoted 5 lines
OK, so we should document somewhere which locks it's OK to take in an OOB command, and then make sure that for each of those locks we add a note saying that anyone taking them must be careful.
We should also add a note above tehqmp_migrate_incomingthat it's an OOB command and to take care.
Makes sense. I think it will be hard to document what locks can be taken during OOB command handing since there can be too many locks there... But at least I can add a comment to qmp_migrate_incoming() along with current patch to note that this function should be OOB friendly from now on.
Quoted 5 lines
However, since you've convinced me it's OK:
Reviewed-by Dr. David Alan Gilbert <[email protected]>
Thanks!
Signature · 1 line
Peter Xu
Re: [Qemu-devel] [RFC v4 21/27] qmp: let migrate-incoming allow out-of-band
Quoted 38 lines · * Peter Xu ([email protected]) wrote:
On Mon, Nov 27, 2017 at 10:44:26AM +0000, Dr. David Alan Gilbert wrote:
[...]
Quoted 28 lines
Quoted 20 lines
Quoted 20 lines
But then I added a break on
pthread_mutex_lock, and I've got this set caused byqemu_start_incoming_migrationsending aMIGRATION_STATUS_SETUPevent:#1
0x0000555555ba6ebainqemu_mutex_lock(mutex=mutex@entry=0x5555563f9ba0 <monitor_lock>)
at/home/dgilbert/git/qemu/util/qemu-thread-posix.c:65
#20x00005555557f01c1inmonitor_qapi_event_queue(event=QAPI_EVENT_MIGRATION, qdict=0x555557d93c00, errp=<optimized out>) at/home/dgilbert/git/qemu/monitor.c:442440
trace_monitor_protocol_event_queue(event, qdict, evconf->rate);
441
442qemu_mutex_lock(&monitor_lock);
443#3
0x0000555555b92722inqapi_event_send_migration(status=status@entry=MIGRATION_STATUS_SETUP, errp=0x555556859320 <error_abort>) at qapi-event.c:661 #40x0000555555a6159finqemu_start_incoming_migration(uri=0x555557693f30 "tcp:0:4444", errp=0x7fffffffc700)
at/home/dgilbert/git/qemu/migration/migration.c:253
#50x0000555555a641c5inqmp_migrate_incoming(uri=0x555557693f30 "tcp:0:4444", errp=0x7fffffffc730)
at/home/dgilbert/git/qemu/migration/migration.c:1321Quoted 7 lines
Quoted 1 line
is there anything which protects us there?
IIUC you mean what if we e.g. page fault during taking the
monitor_lock? IMHO it just can't happen -monitor_lockis really used in limited places and during those critical sections there is no guest memory access at all (which only protects the monitor logic itself AFAICT).Quoted 5 lines
OK, so we should document somewhere which locks it's OK to take in an OOB command, and then make sure that for each of those locks we add a note saying that anyone taking them must be careful.
We should also add a note above tehqmp_migrate_incomingthat it's an OOB command and to take care.
Quoted 3 lines
Makes sense. I think it will be hard to document what locks can be taken during OOB command handing since there can be too many locks there...
Yes, but we need people who are marking commands as OOB to really think about it, otherwise they'll use a lock that in some weird corner case can also be taken by another command that can block.
Quoted 3 lines
But at least I can add a comment to
qmp_migrate_incoming()along with current patch to note that this function should be OOB friendly from now on.
Thanks.
Dave
Quoted 10 lines
Quoted 5 lines
However, since you've convinced me it's OK:
Reviewed-by Dr. David Alan Gilbert <[email protected]>Thanks!
Signature · 1 line
Peter Xu
--
Dr. David Alan Gilbert / [email protected] / Manchester, UK
Re: [Qemu-devel] [RFC v4 21/27] qmp: let migrate-incoming allow out-of-band
Quoted 39 lines · Dr. David Alan Gilbert
Quoted 38 lines · * Peter Xu ([email protected]) wrote:
On Mon, Nov 27, 2017 at 10:44:26AM +0000, Dr. David Alan Gilbert wrote:
[...]
Quoted 33 lines
Quoted 20 lines
Quoted 20 lines
But then I added a break on
pthread_mutex_lock, and I've got this set caused byqemu_start_incoming_migrationsending aMIGRATION_STATUS_SETUPevent:#1
0x0000555555ba6ebainqemu_mutex_lock(mutex=mutex@entry=0x5555563f9ba0 <monitor_lock>)
at/home/dgilbert/git/qemu/util/qemu-thread-posix.c:65
#20x00005555557f01c1inmonitor_qapi_event_queue(event=QAPI_EVENT_MIGRATION, qdict=0x555557d93c00, errp=<optimized out>) at/home/dgilbert/git/qemu/monitor.c:442440
trace_monitor_protocol_event_queue(event, qdict, evconf->rate);
441
442qemu_mutex_lock(&monitor_lock);
443#3
0x0000555555b92722inqapi_event_send_migration(status=status@entry=MIGRATION_STATUS_SETUP, errp=0x555556859320 <error_abort>) at qapi-event.c:661 #40x0000555555a6159finqemu_start_incoming_migration(uri=0x555557693f30 "tcp:0:4444", errp=0x7fffffffc700)
at/home/dgilbert/git/qemu/migration/migration.c:253
#50x0000555555a641c5inqmp_migrate_incoming(uri=0x555557693f30 "tcp:0:4444", errp=0x7fffffffc730)
at/home/dgilbert/git/qemu/migration/migration.c:1321Quoted 7 lines
Quoted 1 line
is there anything which protects us there?
IIUC you mean what if we e.g. page fault during taking the
monitor_lock? IMHO it just can't happen -monitor_lockis really used in limited places and during those critical sections there is no guest memory access at all (which only protects the monitor logic itself AFAICT).OK, so we should document somewhere which locks it's OK to take in an OOB command, and then make sure that for each of those locks we add a note saying that anyone taking them must be careful.
We should also add a note above tehqmp_migrate_incomingthat it's an OOB command and to take care.
Quoted 7 lines
Quoted 3 lines
Makes sense. I think it will be hard to document what locks can be taken during OOB command handing since there can be too many locks there...
Yes, but we need people who are marking commands as OOB to really think about it, otherwise they'll use a lock that in some weird corner case can also be taken by another command that can block.
Right. That sounds like a HOWTO to migrate existing commands to support OOB. Hmm, could there be any/much? I'm curious.
Anyways... how about I add this paragraph to doc patch?
Converting an existing QMP command to be OOB-capable can be either very easy or extremely hard. The most important thing is that, the command should never be blocked unexpectedly in any form. For example, it's still legal to take a mutex in an OOB-capable command handler (but never the BQL!), but we need to make sure that all the other code paths that are protected by the same lock won't be blocked too. Some candidates that can easily block: (1) doing IOs (especially when the backend can be an NFS storage), or (2) accessing guest memories (which can be simply blocked when it triggers a page fault, and which cannot be handled immediately).
Thanks,
-- Peter Xu
RFC v4 22/27 qmp: isolate responses into io thread
In reply to Peter XuFor 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.
--- monitor.c | 97 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++- 1 file changed, 96 insertions(+), 1 deletion(-)
monitor.c +96 -1
@@ -172,6 +172,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;/*
@@ -219,6 +221,8 @@ struct MonitorGlobal {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; };static struct MonitorGlobal mon_global;
@@ -395,7 +399,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;
@@ -409,6 +414,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 },
@@ -595,6 +665,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)
@@ -609,6 +680,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,
@@ -4301,6 +4373,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("monitor_iothread",
@@ -4314,6 +4391,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 )
@@ -4426,6 +4512,13 @@ 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. +*/ +monitor_qmp_bh_responder (NULL ); +qemu_mutex_lock (&monitor_lock); QTAILQ_FOREACH_SAFE(mon, &mon_list, entry, next) {QTAILQ_REMOVE (&mon_list, mon, entry);
@@ -4437,6 +4530,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 ;
Signature · 1 line
2.13.6
RFC v4 23/27 monitor: enable IO thread for (qmp & !mux) typed
In reply to Peter XuStart to use dedicate IO thread for QMP monitors that are not using MUXed chardev.
--- monitor.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-)
monitor.c +2 -1
@@ -36,6 +36,7 @@#include "net/net.h" #include "net/slirp.h" #include "chardev/char-fe.h" +#include "chardev/char-mux.h" #include "ui/qemu-spice.h" #include "sysemu/numa.h" #include "monitor/monitor.h"
@@ -4456,7 +4457,7 @@ void monitor_init(Chardev *chr, int flags)Monitor *mon =g_malloc (sizeof (*mon));GMainContext *context; -monitor_data_init (mon, false, false); +monitor_data_init (mon, false, !CHARDEV_IS_MUX (chr));qemu_chr_fe_init (&mon->chr, chr, &error_abort); mon->flags = flags;
Signature · 1 line
2.13.6
Re: [Qemu-devel] [RFC v4 23/27] monitor: enable IO thread for (qmp & !mux) typed
Quoted 4 lines · * Peter Xu ([email protected]) wrote:
Start to use dedicate IO thread for QMP monitors that are not using MUXed chardev.
Signed-off-by Peter Xu <[email protected]>
I guess another way to do this would be to have a property on the Chardev something like 'can use iothread' and clear that for Mux.
Dave
Quoted 28 lines
--- monitor.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-)monitor.c +2
-1@@ -36,6 +36,7 @@#include "net/net.h" #include "net/slirp.h" #include "chardev/char-fe.h" +#include "chardev/char-mux.h" #include "ui/qemu-spice.h" #include "sysemu/numa.h" #include "monitor/monitor.h" @@ -4456,7 +4457,7 @@ void monitor_init(Chardev *chr, int flags)Monitor *mon =g_malloc (sizeof (*mon));GMainContext *context; -monitor_data_init (mon, false, false); +monitor_data_init (mon, false, !CHARDEV_IS_MUX (chr));qemu_chr_fe_init (&mon->chr, chr, &error_abort); mon->flags = flags;Signature · 1 line
2.13.6
--
Dr. David Alan Gilbert / [email protected] / Manchester, UK
Re: [Qemu-devel] [RFC v4 23/27] monitor: enable IO thread for (qmp & !mux) typed
Quoted 7 lines · Dr. David Alan Gilbert
Quoted 4 lines · * Peter Xu ([email protected]) wrote:
Start to use dedicate IO thread for QMP monitors that are not using MUXed chardev.
Signed-off-by Peter Xu <[email protected]>Reviewed-by Dr. David Alan Gilbert <[email protected]>
Thanks!
Quoted 3 lines
I guess another way to do this would be to have a property on the Chardev something like 'can use iothread' and clear that for Mux.
Yeh we can. Though I would still prefer to put that in Monitor struct since current IOThread is really tailored only for monitors. IOW not all Chardevs can be run in the IOThread (or say, the thread currently named as "mon_iothread") safely. Thanks,
Signature · 1 line
Peter Xu
RFC v4 24/27 qmp: add command "x-oob-test"
In reply to Peter XuThis command is only used to test OOB functionality. It should not be used for any other purposes.
--- qapi-schema.json | 18 ++++++++++++++++++ qmp.c | 16 ++++++++++++++++ 2 files changed, 34 insertions(+)
qapi-schema.json +18 -0
@@ -3256,3 +3256,21 @@ ## { 'event': 'REQUEST_DROPPED' , 'data': { 'id': 'any', 'reason': 'RequestDropReason' } } + +## +# @x-oob-test: +# +# Test OOB functionality. When send this command with lock=true, +# it'll try to hang the dispatcher. When send it with lock=false, +# it'll try to notify the locked thread to continue. Note: it should +# only be used by QMP test program rather than anything else. +# +# Since: 2.12 +# +# Example: +# +# { "execute": "x-oob-test", +# "arguments": { "lock": true } } +## +{ 'command': 'x-oob-test', 'data' : { 'lock': 'bool' }, + 'allow-oob': true }
qmp.c +16 -0
@@ -722,3 +722,19 @@ MemoryInfo *qmp_query_memory_size_summary(Error **errp)return mem_info; } + +static QemuSemaphore x_oob_test_sem; + +static void __attribute__((constructor))x_oob_test_init (void ) +{ +qemu_sem_init (&x_oob_test_sem,0 ); +} + +void qmp_x_oob_test (bool lock,Error **errp) +{ +if (lock) { +qemu_sem_wait (&x_oob_test_sem); + }else { +qemu_sem_post (&x_oob_test_sem); + } +}
Signature · 1 line
2.13.6
RFC v4 25/27 docs: update QMP documents for OOB commands
In reply to Peter XuUpdate both the developer and spec for the new QMP OOB (Out-Of-Band) command.
--- docs/devel/qapi-code-gen.txt | 51 +++++++++++++++++++++++++++++++++++++++----- docs/interop/qmp-spec.txt | 35 +++++++++++++++++++++++++----- 2 files changed, 76 insertions(+), 10 deletions(-)
docs/devel/qapi-code-gen.txt +46 -5
@@ -556,7 +556,8 @@ following example objects: Usage: { 'command': STRING, '*data': COMPLEX-TYPE-NAME-OR-DICT, '*returns': TYPE-NAME, '*boxed': true, - '*gen': false, '*success-response': false } + '*gen': false, '*success-response': false, + '*allow-oob': false } Commands are defined by using a dictionary containing several members, where three members are most common. The 'command' member is a
@@ -636,6 +637,44 @@ possible, the command expression should include the optional key 'success-response' with boolean value false. So far, only QGA makes use of this member. +Most of the QMP commands are handled sequentially in such a order: +Firstly, the JSON Parser parses the command request into some internal +message, delivers the message to QMP dispatchers. Secondly, the QMP +dispatchers will handle the commands one by one in time order, respond +when necessary. For some commands that always complete "quickly" can +instead be executed directly during parsing, at the QMP client's +request. This kind of commands that allow direct execution is called +"out-of-band" ("oob" as shortcut) commands. The response can overtake +prior in-band commands' responses. By default, commands are always +in-band. We need to explicitly specify "allow-oob" to "True" to show +that one command can be run out-of-band. + +One thing to mention for developers is that, although out-of-band +execution of commands benefit from quick and asynchronous execution, +it need to satisfy at least the following: + +(1) It is extremely quick and never blocks, so that its execution will + not block parsing routine of any other monitors. + +(2) It does not need BQL, since the parser can be run without BQL, + while the dispatcher is always with BQL held. + +If not, the command is not suitable to be allowed to run out-of-band, +and it should set its "allow-oob" to "False". Whether a command is +allowed to run out-of-band can also be introspected using +query-qmp-schema command. Please see the section "Client JSON +Protocol introspection" for more information. + +To execute a command in out-of-band way, we need to specify the +"control" field in the request, with "run-oob" set to true. Example: + + => { "execute": "command-support-oob", + "arguments": { ... }, + "control": { "run-oob": true } } + <= { "return": { } } + +Without it, even the commands that supports out-of-band execution will +still be run in-band. === Events ===
@@ -739,10 +778,12 @@ references by name. QAPI schema definitions not reachable that way are omitted. The SchemaInfo for a command has meta-type "command", and variant -members "arg-type" and "ret-type". On the wire, the "arguments" -member of a client's "execute" command must conform to the object type -named by "arg-type". The "return" member that the server passes in a -success response conforms to the type named by "ret-type". +members "arg-type", "ret-type" and "allow-oob". On the wire, the +"arguments" member of a client's "execute" command must conform to the +object type named by "arg-type". The "return" member that the server +passes in a success response conforms to the type named by +"ret-type". When "allow-oob" is set, it means the command supports +out-of-band execution. If the command takes no arguments, "arg-type" names an object type without members. Likewise, if the command returns nothing, "ret-type"
docs/interop/qmp-spec.txt +30 -5
@@ -78,21 +78,32 @@ The greeting message format is: - The "capabilities" member specify the availability of features beyond the baseline specification; the order of elements in this array has no particular significance, so a client must search the entire array - when looking for a particular capability + when looking for a particular capability. 2.2.1 Capabilities ------------------ -As of the date this document was last revised, no server or client -capability strings have been defined. +Currently supported capabilities are: +- "oob": it means the QMP server supports "Out-Of-Band" command + execution. For more detail, please see "run-oob" parameter in + "Issuing Commands" section below. Not all commands allow this "oob" + execution. One can know whether one command supports "oob" by + "query-qmp-schema" command. + +QMP clients can get a list of supported QMP capabilities of the QMP +server in the greeting message mentioned above. By default, all the +capabilities are off. To enable a specific or multiple of QMP +capabilities, QMP client needs to send "qmp_capabilities" command with +extra parameter for the capabilities. 2.3 Issuing Commands -------------------- The format for command execution is: -{ "execute": json-string, "arguments": json-object, "id": json-value } +{ "execute": json-string, "arguments": json-object, "id": json-value, + "control": json-dict } Where,
@@ -102,10 +113,19 @@ The format for command execution is: required. Each command documents what contents will be considered valid when handling the json-argument - The "id" member is a transaction identification associated with the - command execution, it is optional and will be part of the response if + command execution. It is required if OOB is enabled, and optional + if not. The same "id" field will be part of the response if provided. The "id" member can be any json-value, although most clients merely use a json-number incremented for each successive command +- The "control" member is optionally, and currently only used for + "out-of-band" execution. For some commands that always complete + "quickly" can be executed directly during parsing at the QMP + client's request. This kind of commands that allow direct execution + is called "out-of-band" ("oob" as shortcut) commands. The response + of "oob" commands can overtake prior in-band commands' responses. + To enable "oob" feature, just provide a control field with: + { "control": { "run-oob": true } } 2.4 Commands Responses ----------------------
@@ -113,6 +133,11 @@ The format for command execution is: There are two possible responses which the Server will issue as the result of a command execution: success or error. +As long as the commands were issued with a proper "id" field, then the +same "id" field will be attached in the corresponding response message +so that requests and responses can match. Clients should drop all the +responses that are with unknown "id" field. + 2.4.1 success -------------
Signature · 1 line
2.13.6
RFC v4 26/27 tests: qmp-test: verify command batching
In reply to Peter XuOOB introduced DROP event for flow control. This should not affect old QMP clients. Add a command batching check to make sure of it.
--- tests/qmp-test.c | 19 +++++++++++++++++++ 1 file changed, 19 insertions(+)
tests/qmp-test.c +19 -0
@@ -78,6 +78,7 @@ static void test_qmp_protocol(void)QList *capabilities;const QListEntry *entry;QString *qstr; +int i; global_qtest =qtest_init_without_qmp_handshake (common_args);
@@ -135,6 +136,24 @@ static void test_qmp_protocol(void) g_assert_cmpint(qdict_get_int(resp, "id"), ==, 2);QDECREF (resp); +/* +* Test command batching. In current test OOB is not enabled, we +* should be able to run as many commands in batch as we like. +* Using 16 (>8, which is OOB queue length) to make sure OOB +* won't break existing clients. +*/ +for (i =0 ; i <16 ; i++) { +qmp_async ("{ 'execute': 'query-version' }" ); + } +/* Verify the replies to make sure no command is dropped. */ +for (i =0 ; i <16 ; i++) { + resp =qmp_receive (); +/* It should never be dropped. Each of them should be a reply. */ +g_assert (qdict_haskey (resp,"return" )); +g_assert (!qdict_haskey (resp,"event" )); +QDECREF (resp); + } +qtest_end (); }
Signature · 1 line
2.13.6
RFC v4 27/27 tests: qmp-test: add oob test
In reply to Peter XuTest the new OOB capability. Here we used the new "x-oob-test" command. Firstly, we send a lock=true and oob=false command to hang the main thread. Then send another lock=false and oob=true command (which will be run inside parser this time) to free that hanged command.
--- tests/qmp-test.c | 61 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 61 insertions(+)
tests/qmp-test.c +61 -0
@@ -157,6 +157,66 @@ static void test_qmp_protocol(void)qtest_end (); } +/* Tests for Out-Of-Band support. */ +static void test_qmp_oob (void ) +{ +QDict *resp; +int acks =0 ; +const char *cmd_id; + + global_qtest =qtest_init_without_qmp_handshake (common_args); + +/* Ignore the greeting message. */ + resp =qmp_receive (); +g_assert (qdict_get_qdict (resp,"QMP" )); +QDECREF (resp); + +/* Try a fake capability, it should fail. */ + resp =qmp ("{ 'execute': 'qmp_capabilities', " +" 'arguments': { 'enable': [ 'cap-does-not-exist' ] } }" ); +g_assert (qdict_haskey (resp,"error" )); + +/* Now, enable OOB in current QMP session, it should success. */ + resp =qmp ("{ 'execute': 'qmp_capabilities', " +" 'arguments': { 'enable': [ 'oob' ] } }" ); +g_assert (qdict_haskey (resp,"return" )); + +/* +* Try any command that does not support OOB but with OOB flag. We +* should get failure. +*/ + resp =qmp ("{ 'execute': 'query-cpus'," +" 'control': { 'run-oob': true } }" ); +g_assert (qdict_haskey (resp,"error" )); + +/* +* Firstly send the "x-oob-test" command with lock=true and +* oob=false, it should hang the dispatcher and main thread; +* later, we send another lock=false with oob=true to continue +* that thread processing. Finally we should receive replies from +* both commands. +*/ +qmp_async ("{ 'execute': 'x-oob-test'," +" 'arguments': { 'lock': true }, " +" 'id': 'lock-cmd'}" ); +qmp_async ("{ 'execute': 'x-oob-test', " +" 'arguments': { 'lock': false }, " +" 'control': { 'run-oob': true }, " +" 'id': 'unlock-cmd' }" ); + +/* Ignore all events. Wait for 2 acks */ +while (acks <2 ) { + resp =qmp_receive (); + cmd_id =qdict_get_str (resp,"id" ); +if (!g_strcmp0 (cmd_id,"lock-cmd" ) || + !g_strcmp0 (cmd_id,"unlock-cmd" )) { + acks++; + } + } + +qtest_end (); +} +static int query_error_class (const char *cmd) { static struct {
@@ -335,6 +395,7 @@ int main(int argc, char *argv[])g_test_init (&argc, &argv,NULL );qtest_add_func ("qmp/protocol" , test_qmp_protocol); +qtest_add_func ("qmp/oob" , test_qmp_oob);qmp_schema_init (&schema);add_query_tests (&schema);
Signature · 1 line
2.13.6