All of lore.kernel.org
 help / color / mirror / Atom feed
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>,
	Jiri Denemark <jdenemar@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>,
	marcandre.lureau@redhat.com,
	Markus Armbruster <armbru@redhat.com>,
	"Dr . David Alan Gilbert" <dgilbert@redhat.com>
Subject: [Qemu-devel] [RFC v3 25/27] docs: update QMP documents for OOB commands
Date: Mon,  6 Nov 2017 17:46:41 +0800	[thread overview]
Message-ID: <20171106094643.14881-26-peterx@redhat.com> (raw)
In-Reply-To: <20171106094643.14881-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    | 32 +++++++++++++++++++++++----
 2 files changed, 74 insertions(+), 9 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..b289e66924 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,
 
@@ -106,6 +117,14 @@ The format for command execution is:
   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 +132,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.5

  parent reply	other threads:[~2017-11-06  9:51 UTC|newest]

Thread overview: 65+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-11-06  9:46 [Qemu-devel] [RFC v3 00/27] QMP: out-of-band (OOB) execution support Peter Xu
2017-11-06  9:46 ` [Qemu-devel] [RFC v3 01/27] char-io: fix possible race on IOWatchPoll Peter Xu
2017-11-07  6:43   ` Fam Zheng
2017-11-13 16:52   ` Stefan Hajnoczi
2017-11-14  6:09     ` Peter Xu
2017-11-14 10:32       ` Stefan Hajnoczi
2017-11-14 11:31         ` Peter Xu
2017-11-15  9:37           ` Stefan Hajnoczi
2017-11-15  9:48             ` Peter Xu
2017-11-06  9:46 ` [Qemu-devel] [RFC v3 02/27] qobject: introduce qstring_get_try_str() Peter Xu
2017-11-07  6:47   ` Fam Zheng
2017-11-06  9:46 ` [Qemu-devel] [RFC v3 03/27] qobject: introduce qobject_get_try_str() Peter Xu
2017-11-07  6:48   ` Fam Zheng
2017-11-06  9:46 ` [Qemu-devel] [RFC v3 04/27] qobject: let object_property_get_str() use new API Peter Xu
2017-11-07  6:50   ` Fam Zheng
2017-11-06  9:46 ` [Qemu-devel] [RFC v3 05/27] monitor: move skip_flush into monitor_data_init Peter Xu
2017-11-07  6:51   ` Fam Zheng
2017-11-06  9:46 ` [Qemu-devel] [RFC v3 06/27] qjson: add "opaque" field to JSONMessageParser Peter Xu
2017-11-07  6:54   ` Fam Zheng
2017-11-06  9:46 ` [Qemu-devel] [RFC v3 07/27] monitor: move the cur_mon hack deeper for QMP Peter Xu
2017-11-07  6:58   ` Fam Zheng
2017-11-06  9:46 ` [Qemu-devel] [RFC v3 08/27] monitor: unify global init Peter Xu
2017-11-07  7:03   ` Fam Zheng
2017-11-06  9:46 ` [Qemu-devel] [RFC v3 09/27] monitor: let mon_list be tail queue Peter Xu
2017-11-07  7:05   ` Fam Zheng
2017-11-06  9:46 ` [Qemu-devel] [RFC v3 10/27] monitor: create monitor dedicate iothread Peter Xu
2017-11-07  7:11   ` Fam Zheng
2017-11-08  7:25     ` Peter Xu
2017-11-08 11:18       ` Fam Zheng
2017-11-08 11:35         ` Peter Xu
2017-11-06  9:46 ` [Qemu-devel] [RFC v3 11/27] monitor: allow to use IO thread for parsing Peter Xu
2017-11-07  7:17   ` Fam Zheng
2017-11-06  9:46 ` [Qemu-devel] [RFC v3 12/27] qmp: introduce QMPCapability Peter Xu
2017-11-06  9:46 ` [Qemu-devel] [RFC v3 13/27] qmp: negociate QMP capabilities Peter Xu
2017-11-06  9:46 ` [Qemu-devel] [RFC v3 14/27] qmp: introduce some capability helpers Peter Xu
2017-11-06  9:46 ` [Qemu-devel] [RFC v3 15/27] monitor: introduce monitor_qmp_respond() Peter Xu
2017-11-07  7:24   ` Fam Zheng
2017-11-06  9:46 ` [Qemu-devel] [RFC v3 16/27] monitor: let monitor_{suspend|resume} thread safe Peter Xu
2017-11-07  7:26   ` Fam Zheng
2017-11-06  9:46 ` [Qemu-devel] [RFC v3 17/27] monitor: separate QMP parser and dispatcher Peter Xu
2017-11-06  9:46 ` [Qemu-devel] [RFC v3 18/27] qmp: add new event "request-dropped" Peter Xu
2017-11-15 10:50   ` Stefan Hajnoczi
2017-11-16  5:56     ` Peter Xu
2017-11-16  6:29       ` Peter Xu
2017-11-16  6:49         ` Peter Xu
2017-11-06  9:46 ` [Qemu-devel] [RFC v3 19/27] monitor: send event when request queue full Peter Xu
2017-11-06  9:46 ` [Qemu-devel] [RFC v3 20/27] qapi: introduce new cmd option "allow-oob" Peter Xu
2017-11-06  9:46 ` [Qemu-devel] [RFC v3 21/27] qmp: support out-of-band (oob) execution Peter Xu
2017-11-06  9:46 ` [Qemu-devel] [RFC v3 22/27] qmp: let migrate-incoming allow out-of-band Peter Xu
2017-11-06  9:46 ` [Qemu-devel] [RFC v3 23/27] qmp: isolate responses into io thread Peter Xu
2017-11-07  7:57   ` Fam Zheng
2017-11-08  7:31     ` Peter Xu
2017-11-08 11:16       ` Fam Zheng
2017-11-06  9:46 ` [Qemu-devel] [RFC v3 24/27] monitor: enable IO thread for (qmp & !mux) typed Peter Xu
2017-11-06  9:46 ` Peter Xu [this message]
2017-11-06  9:46 ` [Qemu-devel] [RFC v3 26/27] tests: qmp-test: verify command batching Peter Xu
2017-11-06  9:46 ` [Qemu-devel] [RFC v3 27/27] tests: qmp-test: add oob test Peter Xu
2017-11-15 10:21   ` Stefan Hajnoczi
2017-11-16  8:02     ` Peter Xu
2017-11-06 10:12 ` [Qemu-devel] [RFC v3 00/27] QMP: out-of-band (OOB) execution support no-reply
2017-11-06 13:08   ` Peter Xu
2017-11-15  9:42     ` Stefan Hajnoczi
2017-11-16  5:32       ` Peter Xu
2017-11-16  5:39         ` Fam Zheng
2017-11-16  6:36           ` 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=20171106094643.14881-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=jdenemar@redhat.com \
    --cc=lvivier@redhat.com \
    --cc=marcandre.lureau@redhat.com \
    --cc=mdroth@linux.vnet.ibm.com \
    --cc=pbonzini@redhat.com \
    --cc=qemu-devel@nongnu.org \
    --cc=quintela@redhat.com \
    --cc=shajnocz@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.