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 v7 01/23] docs: update QMP documents for OOB commands
Date: Wed, 24 Jan 2018 13:39:35 +0800	[thread overview]
Message-ID: <20180124053957.29145-2-peterx@redhat.com> (raw)
In-Reply-To: <20180124053957.29145-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 | 68 ++++++++++++++++++++++++++++++++++++++++----
 docs/interop/qmp-spec.txt    | 30 ++++++++++++++++---
 2 files changed, 89 insertions(+), 9 deletions(-)

diff --git a/docs/devel/qapi-code-gen.txt b/docs/devel/qapi-code-gen.txt
index 06ab699066..4d3db0ad39 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': false }
 
 Commands are defined by using a dictionary containing several members,
 where three members are most common.  The 'command' member is a
@@ -636,6 +639,59 @@ 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 to support
+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.
+
+Please read the "Out-Of-Band Command Execution" section below for more
+information on how OOB execution works.
+
+--- 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.
+
+When we say normal QMP command executions, it means basically the
+following:
+
+- They are executed in order,
+- They run only in main thread of QEMU,
+- They have the BQL taken during execution.
+
+For OOB command executions, they differ in the following:
+
+- They can be executed before an existing 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 +795,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..e20163c138 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 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,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" feature, 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-01-24  5:40 UTC|newest]

Thread overview: 50+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-01-24  5:39 [Qemu-devel] [PATCH v7 00/23] QMP: out-of-band (OOB) execution support Peter Xu
2018-01-24  5:39 ` Peter Xu [this message]
2018-02-09 14:10   ` [Qemu-devel] [PATCH v7 01/23] docs: update QMP documents for OOB commands Eric Blake
2018-02-11  5:34     ` Peter Xu
2018-01-24  5:39 ` [Qemu-devel] [PATCH v7 02/23] qobject: introduce qstring_get_try_str() Peter Xu
2018-01-24  5:39 ` [Qemu-devel] [PATCH v7 03/23] qobject: introduce qobject_get_try_str() Peter Xu
2018-01-24  5:39 ` [Qemu-devel] [PATCH v7 04/23] qobject: let object_property_get_str() use new API Peter Xu
2018-01-24  5:39 ` [Qemu-devel] [PATCH v7 05/23] monitor: move skip_flush into monitor_data_init Peter Xu
2018-01-24  5:39 ` [Qemu-devel] [PATCH v7 06/23] monitor: move the cur_mon hack deeper for QMP Peter Xu
2018-01-24  5:39 ` [Qemu-devel] [PATCH v7 07/23] monitor: unify global init Peter Xu
2018-01-24  5:39 ` [Qemu-devel] [PATCH v7 08/23] monitor: let mon_list be tail queue Peter Xu
2018-01-24  5:39 ` [Qemu-devel] [PATCH v7 09/23] monitor: allow using IO thread for parsing Peter Xu
2018-02-21 16:00   ` Stefan Hajnoczi
2018-02-22 10:01     ` Peter Xu
2018-02-22 15:41       ` Stefan Hajnoczi
2018-02-22 15:50       ` Daniel P. Berrangé
2018-02-23  2:56         ` Peter Xu
2018-01-24  5:39 ` [Qemu-devel] [PATCH v7 10/23] qmp: introduce QMPCapability Peter Xu
2018-02-21 16:17   ` Stefan Hajnoczi
2018-02-22 10:42     ` Peter Xu
2018-01-24  5:39 ` [Qemu-devel] [PATCH v7 11/23] monitor: introduce monitor_qmp_respond() Peter Xu
2018-01-24  5:39 ` [Qemu-devel] [PATCH v7 12/23] monitor: let suspend_cnt be thread safe Peter Xu
2018-02-21 16:44   ` Stefan Hajnoczi
2018-02-21 16:45   ` Stefan Hajnoczi
2018-02-21 16:45   ` Stefan Hajnoczi
2018-01-24  5:39 ` [Qemu-devel] [PATCH v7 13/23] monitor: let suspend/resume work even with QMPs Peter Xu
2018-02-21 16:50   ` Stefan Hajnoczi
2018-02-22 10:49     ` Peter Xu
2018-01-24  5:39 ` [Qemu-devel] [PATCH v7 14/23] monitor: separate QMP parser and dispatcher Peter Xu
2018-02-21 17:17   ` Stefan Hajnoczi
2018-01-24  5:39 ` [Qemu-devel] [PATCH v7 15/23] qmp: add new event "command-dropped" Peter Xu
2018-02-21 17:19   ` Stefan Hajnoczi
2018-01-24  5:39 ` [Qemu-devel] [PATCH v7 16/23] monitor: send event when command queue full Peter Xu
2018-02-21 17:23   ` Stefan Hajnoczi
2018-01-24  5:39 ` [Qemu-devel] [PATCH v7 17/23] qapi: introduce new cmd option "allow-oob" Peter Xu
2018-03-08 10:04   ` Igor Mammedov
2018-03-08 11:43     ` Peter Xu
2018-03-08 11:51     ` Peter Xu
2018-01-24  5:39 ` [Qemu-devel] [PATCH v7 18/23] qmp: support out-of-band (oob) execution Peter Xu
2018-02-21 17:34   ` Stefan Hajnoczi
2018-01-24  5:39 ` [Qemu-devel] [PATCH v7 19/23] qmp: isolate responses into io thread Peter Xu
2018-02-21 17:44   ` Stefan Hajnoczi
2018-01-24  5:39 ` [Qemu-devel] [PATCH v7 20/23] monitor: enable IO thread for (qmp & !mux) typed Peter Xu
2018-01-24  5:39 ` [Qemu-devel] [PATCH v7 21/23] qmp: add command "x-oob-test" Peter Xu
2018-01-24  5:39 ` [Qemu-devel] [PATCH v7 22/23] tests: qmp-test: verify command batching Peter Xu
2018-01-24  5:39 ` [Qemu-devel] [PATCH v7 23/23] tests: qmp-test: add oob test Peter Xu
2018-01-25  2:35 ` [Qemu-devel] [PATCH v7 00/23] QMP: out-of-band (OOB) execution support Peter Xu
2018-01-25 10:01   ` Dr. David Alan Gilbert
2018-02-08  6:44 ` Peter Xu
2018-02-21 17:45 ` Stefan Hajnoczi

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=20180124053957.29145-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).