qemu-devel.nongnu.org archive mirror
 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>,
	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] [PATCH v8 01/23] docs: update QMP documents for OOB commands
Date: Fri,  9 Mar 2018 16:59:44 +0800	[thread overview]
Message-ID: <20180309090006.10018-2-peterx@redhat.com> (raw)
In-Reply-To: <20180309090006.10018-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 | 65 ++++++++++++++++++++++++++++++++++++++++----
 docs/interop/qmp-spec.txt    | 30 +++++++++++++++++---
 2 files changed, 86 insertions(+), 9 deletions(-)

diff --git a/docs/devel/qapi-code-gen.txt b/docs/devel/qapi-code-gen.txt
index 25b7180a18..05fe8676af 100644
--- a/docs/devel/qapi-code-gen.txt
+++ b/docs/devel/qapi-code-gen.txt
@@ -554,9 +554,12 @@ following example objects:
 
 === Commands ===
 
+--- General Command Layout ---
+
 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': true }
 
 Commands are defined by using a dictionary containing several members,
 where three members are most common.  The 'command' member is a
@@ -636,6 +639,56 @@ possible, the command expression should include the optional key
 'success-response' with boolean value false.  So far, only QGA makes
 use of this member.
 
+A command can be declared to support Out-Of-Band (OOB) execution.  By
+default, commands do not support OOB.  To declare a command that
+supports it, we need an extra 'allow-oob' field.  For example:
+
+ { 'command': 'migrate_recover',
+   'data': { 'uri': 'str' }, 'allow-oob': true }
+
+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 support out-of-band execution will
+still be run In-Band.
+
+--- About Out-Of-Band (OOB) Command Execution ---
+
+Out-Of-Band does not mean a special kind of command. Instead, it's a
+special way to execute the command.  One normal command can be
+declared to support Out-Of-Band execution when 'allow-oob' field is
+set to true when defining the command.  With that, it can be run in an
+Out-Of-Band way if 'run-oob' is specified in 'control' field of
+command request.
+
+Under normal QMP command execution, the following apply to each
+command:
+
+- They are executed in order,
+- They run only in main thread of QEMU,
+- They have the BQL taken during execution.
+
+When a command is executed with OOB, the following changes occur:
+
+- They can be completed before a pending in-band command,
+- They run in a monitor dedicated thread,
+- They do not take the BQL during execution.
+
+OOB command handlers must satisfy the following conditions:
+
+- It executes extremely fast,
+- It does not take any lock, or, it can take very small locks if all
+  critical regions also follow the rules for OOB command handler code,
+- It does not invoke system calls that may block,
+- It does not access guest RAM that may block when userfaultfd is
+  enabled for postcopy live migration.
+
+If in doubt, do not implement OOB execution support.
 
 === Events ===
 
@@ -739,10 +792,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..9a208589f6 100644
--- a/docs/interop/qmp-spec.txt
+++ b/docs/interop/qmp-spec.txt
@@ -83,16 +83,27 @@ The greeting message format is:
 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 details, please see "run-oob" parameter in
+  "Issuing Commands" section below.  Not all commands allow this "oob"
+  execution.  The "query-qmp-schema" command can be used to inspect
+  which commands support "oob" execution.
+
+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 any QMP capabilities, the QMP client
+needs to send the "qmp_capabilities" command with an extra parameter
+for the requested 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,16 @@ 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 optional, and currently only used for
+  "out-of-band" execution ("oob" as shortcut). The handling or
+  response of an "oob" command can overtake prior in-band commands.
+  To enable "oob" handling of a particular command, just provide a
+  control field with: { "control": { "run-oob": true } }
 
 2.4 Commands Responses
 ----------------------
@@ -113,6 +130,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.14.3

  reply	other threads:[~2018-03-09  9:00 UTC|newest]

Thread overview: 78+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-03-09  8:59 [Qemu-devel] [PATCH v8 00/23] QMP: out-of-band (OOB) execution support Peter Xu
2018-03-09  8:59 ` Peter Xu [this message]
2018-03-09 17:13   ` [Qemu-devel] [PATCH v8 01/23] docs: update QMP documents for OOB commands Eric Blake
2018-03-12  3:32     ` Peter Xu
2018-03-09  8:59 ` [Qemu-devel] [PATCH v8 02/23] qobject: introduce qstring_get_try_str() Peter Xu
2018-03-09  8:59 ` [Qemu-devel] [PATCH v8 03/23] qobject: introduce qobject_get_try_str() Peter Xu
2018-03-09 20:10   ` Eric Blake
2018-03-09  8:59 ` [Qemu-devel] [PATCH v8 04/23] qobject: let object_property_get_str() use new API Peter Xu
2018-03-09  8:59 ` [Qemu-devel] [PATCH v8 05/23] monitor: move skip_flush into monitor_data_init Peter Xu
2018-03-09  8:59 ` [Qemu-devel] [PATCH v8 06/23] monitor: move the cur_mon hack deeper for QMP Peter Xu
2018-03-10 23:13   ` Eric Blake
2018-03-09  8:59 ` [Qemu-devel] [PATCH v8 07/23] monitor: unify global init Peter Xu
2018-03-09  8:59 ` [Qemu-devel] [PATCH v8 08/23] monitor: let mon_list be tail queue Peter Xu
2018-03-09  8:59 ` [Qemu-devel] [PATCH v8 09/23] monitor: allow using IO thread for parsing Peter Xu
2018-03-10 23:19   ` Eric Blake
2018-03-09  8:59 ` [Qemu-devel] [PATCH v8 10/23] qmp: introduce QMPCapability Peter Xu
2018-03-11  1:25   ` Eric Blake
2018-03-09  8:59 ` [Qemu-devel] [PATCH v8 11/23] monitor: introduce monitor_qmp_respond() Peter Xu
2018-03-11  1:35   ` Eric Blake
2018-03-09  8:59 ` [Qemu-devel] [PATCH v8 12/23] monitor: let suspend_cnt be thread safe Peter Xu
2018-03-09  8:59 ` [Qemu-devel] [PATCH v8 13/23] monitor: let suspend/resume work even with QMPs Peter Xu
2018-03-11  1:53   ` Eric Blake
2018-03-09  8:59 ` [Qemu-devel] [PATCH v8 14/23] monitor: separate QMP parser and dispatcher Peter Xu
2018-03-11  2:00   ` Eric Blake
2018-03-21 18:01   ` Marc-André Lureau
2018-03-21 20:09     ` Dr. David Alan Gilbert
2018-03-21 20:33       ` Eric Blake
2018-03-21 23:32         ` Marc-André Lureau
2018-03-22  5:00           ` Peter Xu
2018-03-22 13:24             ` Eric Blake
2018-03-23 16:18   ` Marc-André Lureau
2018-03-26  8:07     ` Peter Xu
2018-03-26  8:33       ` Marc-André Lureau
2018-03-26  9:08         ` Peter Xu
2018-03-26  9:46           ` Marc-André Lureau
2018-03-28  4:02             ` Peter Xu
2018-04-04 13:58               ` Marc-André Lureau
2018-04-08  3:02                 ` Peter Xu
2018-04-09  9:19                   ` Marc-André Lureau
2018-04-10  7:15                     ` Peter Xu
2018-04-10  7:56                       ` Peter Xu
2018-03-09  8:59 ` [Qemu-devel] [PATCH v8 15/23] qmp: add new event "command-dropped" Peter Xu
2018-03-11  2:03   ` Eric Blake
2018-03-09  8:59 ` [Qemu-devel] [PATCH v8 16/23] monitor: send event when command queue full Peter Xu
2018-03-11  2:11   ` Eric Blake
2018-03-09  9:00 ` [Qemu-devel] [PATCH v8 17/23] qapi: introduce new cmd option "allow-oob" Peter Xu
2018-03-11  2:27   ` Eric Blake
2018-03-12  3:35     ` Peter Xu
2018-03-09  9:00 ` [Qemu-devel] [PATCH v8 18/23] qmp: support out-of-band (oob) execution Peter Xu
2018-03-11  2:37   ` Eric Blake
2018-03-22 10:22   ` Marc-André Lureau
2018-03-23  5:18     ` Peter Xu
2018-03-23 10:03       ` Marc-André Lureau
2018-03-09  9:00 ` [Qemu-devel] [PATCH v8 19/23] qmp: isolate responses into io thread Peter Xu
2018-03-22 12:00   ` Marc-André Lureau
2018-03-23  5:50     ` Peter Xu
2018-03-23 10:00       ` Marc-André Lureau
2018-03-09  9:00 ` [Qemu-devel] [PATCH v8 20/23] monitor: enable IO thread for (qmp & !mux) typed Peter Xu
2018-03-23 12:10   ` Christian Borntraeger
2018-03-23 12:25     ` Peter Xu
2018-03-23 12:44       ` Christian Borntraeger
2018-03-23 13:01         ` Peter Xu
2018-03-23 13:21           ` Peter Maydell
2018-03-23 13:23           ` Christian Borntraeger
2018-03-23 13:39             ` Peter Xu
2018-03-09  9:00 ` [Qemu-devel] [PATCH v8 21/23] qmp: add command "x-oob-test" Peter Xu
2018-03-11  2:42   ` Eric Blake
2018-03-09  9:00 ` [Qemu-devel] [PATCH v8 22/23] tests: qmp-test: verify command batching Peter Xu
2018-03-11  2:45   ` Eric Blake
2018-03-12  3:43     ` Peter Xu
2018-03-09  9:00 ` [Qemu-devel] [PATCH v8 23/23] tests: qmp-test: add oob test Peter Xu
2018-03-11  2:49   ` Eric Blake
2018-03-12  3:56     ` Peter Xu
2018-03-11  2:59 ` [Qemu-devel] [PATCH v8 00/23] QMP: out-of-band (OOB) execution support Eric Blake
2018-03-12  4:14   ` Peter Xu
2018-03-12 12:01 ` Eric Blake
2018-03-12 12:55   ` Daniel P. Berrangé
2018-03-13  2:06     ` 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=20180309090006.10018-2-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).