From: Peter Xu <peterx@redhat.com>
To: qemu-devel@nongnu.org
Cc: Stefan Hajnoczi <shajnocz@redhat.com>,
"Daniel P . Berrange" <berrange@redhat.com>,
Paolo Bonzini <pbonzini@redhat.com>, Fam Zheng <famz@redhat.com>,
Juan Quintela <quintela@redhat.com>,
mdroth@linux.vnet.ibm.com, peterx@redhat.com,
Eric Blake <eblake@redhat.com>,
Laurent Vivier <lvivier@redhat.com>,
Markus Armbruster <armbru@redhat.com>,
marcandre.lureau@redhat.com,
"Dr . David Alan Gilbert" <dgilbert@redhat.com>
Subject: [Qemu-devel] [RFC v4 25/27] docs: update QMP documents for OOB commands
Date: Thu, 16 Nov 2017 21:06:08 +0800 [thread overview]
Message-ID: <20171116130610.23582-26-peterx@redhat.com> (raw)
In-Reply-To: <20171116130610.23582-1-peterx@redhat.com>
Update both the developer and spec for the new QMP OOB (Out-Of-Band)
command.
Signed-off-by: Peter Xu <peterx@redhat.com>
---
docs/devel/qapi-code-gen.txt | 51 +++++++++++++++++++++++++++++++++++++++-----
docs/interop/qmp-spec.txt | 35 +++++++++++++++++++++++++-----
2 files changed, 76 insertions(+), 10 deletions(-)
diff --git a/docs/devel/qapi-code-gen.txt b/docs/devel/qapi-code-gen.txt
index f04c63fe82..8597fdb087 100644
--- a/docs/devel/qapi-code-gen.txt
+++ b/docs/devel/qapi-code-gen.txt
@@ -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"
diff --git a/docs/interop/qmp-spec.txt b/docs/interop/qmp-spec.txt
index f8b5356015..c5c02589a9 100644
--- a/docs/interop/qmp-spec.txt
+++ b/docs/interop/qmp-spec.txt
@@ -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
-------------
--
2.13.6
next prev parent reply other threads:[~2017-11-16 13:08 UTC|newest]
Thread overview: 42+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-11-16 13:05 [Qemu-devel] [RFC v4 00/27] QMP: out-of-band (OOB) execution support Peter Xu
2017-11-16 13:05 ` [Qemu-devel] [RFC v4 01/27] qobject: introduce qstring_get_try_str() Peter Xu
2017-11-16 13:05 ` [Qemu-devel] [RFC v4 02/27] qobject: introduce qobject_get_try_str() Peter Xu
2017-11-16 13:05 ` [Qemu-devel] [RFC v4 03/27] qobject: let object_property_get_str() use new API Peter Xu
2017-11-16 13:05 ` [Qemu-devel] [RFC v4 04/27] monitor: move skip_flush into monitor_data_init Peter Xu
2017-11-16 13:05 ` [Qemu-devel] [RFC v4 05/27] qjson: add "opaque" field to JSONMessageParser Peter Xu
2017-11-16 13:05 ` [Qemu-devel] [RFC v4 06/27] monitor: move the cur_mon hack deeper for QMP Peter Xu
2017-11-16 13:05 ` [Qemu-devel] [RFC v4 07/27] monitor: unify global init Peter Xu
2017-11-16 13:05 ` [Qemu-devel] [RFC v4 08/27] monitor: let mon_list be tail queue Peter Xu
2017-11-16 13:05 ` [Qemu-devel] [RFC v4 09/27] monitor: create monitor dedicate iothread Peter Xu
2017-11-23 10:46 ` Dr. David Alan Gilbert
2017-11-23 10:51 ` Dr. David Alan Gilbert
2017-11-23 10:53 ` Daniel P. Berrange
2017-11-24 7:36 ` Peter Xu
2017-11-16 13:05 ` [Qemu-devel] [RFC v4 10/27] monitor: allow to use IO thread for parsing Peter Xu
2017-11-16 13:05 ` [Qemu-devel] [RFC v4 11/27] qmp: introduce QMPCapability Peter Xu
2017-11-16 13:05 ` [Qemu-devel] [RFC v4 12/27] qmp: negociate QMP capabilities Peter Xu
2017-11-16 13:05 ` [Qemu-devel] [RFC v4 13/27] qmp: introduce some capability helpers Peter Xu
2017-11-16 13:05 ` [Qemu-devel] [RFC v4 14/27] monitor: introduce monitor_qmp_respond() Peter Xu
2017-11-16 13:05 ` [Qemu-devel] [RFC v4 15/27] monitor: let monitor_{suspend|resume} thread safe Peter Xu
2017-11-23 11:23 ` Dr. David Alan Gilbert
2017-11-24 7:58 ` Peter Xu
2017-11-16 13:05 ` [Qemu-devel] [RFC v4 16/27] monitor: separate QMP parser and dispatcher Peter Xu
2017-11-16 13:06 ` [Qemu-devel] [RFC v4 17/27] qmp: add new event "request-dropped" Peter Xu
2017-11-16 13:06 ` [Qemu-devel] [RFC v4 18/27] monitor: send event when request queue full Peter Xu
2017-11-16 13:06 ` [Qemu-devel] [RFC v4 19/27] qapi: introduce new cmd option "allow-oob" Peter Xu
2017-11-16 13:06 ` [Qemu-devel] [RFC v4 20/27] qmp: support out-of-band (oob) execution Peter Xu
2017-11-16 13:06 ` [Qemu-devel] [RFC v4 21/27] qmp: let migrate-incoming allow out-of-band Peter Xu
2017-11-24 13:14 ` Dr. David Alan Gilbert
2017-11-27 5:20 ` Peter Xu
2017-11-27 10:44 ` Dr. David Alan Gilbert
2017-11-27 10:54 ` Peter Xu
2017-11-27 11:04 ` Dr. David Alan Gilbert
2017-11-27 11:26 ` Peter Xu
2017-11-16 13:06 ` [Qemu-devel] [RFC v4 22/27] qmp: isolate responses into io thread Peter Xu
2017-11-16 13:06 ` [Qemu-devel] [RFC v4 23/27] monitor: enable IO thread for (qmp & !mux) typed Peter Xu
2017-11-24 11:01 ` Dr. David Alan Gilbert
2017-11-27 3:00 ` Peter Xu
2017-11-16 13:06 ` [Qemu-devel] [RFC v4 24/27] qmp: add command "x-oob-test" Peter Xu
2017-11-16 13:06 ` Peter Xu [this message]
2017-11-16 13:06 ` [Qemu-devel] [RFC v4 26/27] tests: qmp-test: verify command batching Peter Xu
2017-11-16 13:06 ` [Qemu-devel] [RFC v4 27/27] tests: qmp-test: add oob test Peter Xu
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20171116130610.23582-26-peterx@redhat.com \
--to=peterx@redhat.com \
--cc=armbru@redhat.com \
--cc=berrange@redhat.com \
--cc=dgilbert@redhat.com \
--cc=eblake@redhat.com \
--cc=famz@redhat.com \
--cc=lvivier@redhat.com \
--cc=marcandre.lureau@redhat.com \
--cc=mdroth@linux.vnet.ibm.com \
--cc=pbonzini@redhat.com \
--cc=qemu-devel@nongnu.org \
--cc=quintela@redhat.com \
--cc=shajnocz@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).