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

On 01/23/2018 11:39 PM, Peter Xu wrote:
> 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 }
>   

Shouldn't this be '*allow-oob': true, as the only time you add the field 
is if you turn oob on (as it already defaults to off)?

>   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

s/to support/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": { } }

This talks more about the QMP user protocol, while the rest of the 
document is about QAPI constructs.  But we do have an example of 
'my-first-command' in the document, so I guess this is okay.

> +
> +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 ---

Do we really need the paragraph mentioning a forward reference, when the 
very next thing is the item that was referenced?

> +
> +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:


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.
> +
> +For OOB command executions, they differ in the following:

When a command is executed with OOB, the following changes occur:

> +
> +- They can be executed before an existing command,

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 +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

s/detail/details/

> +  "Issuing Commands" section below.  Not all commands allow this "oob"
> +  execution.  One can know whether one command supports "oob" by
> +  "query-qmp-schema" command.

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 a specific or multiple of QMP

s/specific or multiple of/any/

> +capabilities, QMP client needs to send "qmp_capabilities" command with

s/QMP/the QMP
s/send/send the/
s/with/with an/

> +extra parameter for the capabilities.

s/the/the requested/

>   
>   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: {

To enable "oob" handling of a particular command,

> +  "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
>   -------------
>   
> 

-- 
Eric Blake, Principal Software Engineer
Red Hat, Inc.           +1-919-301-3266
Virtualization:  qemu.org | libvirt.org

On Fri, Feb 09, 2018 at 08:10:53AM -0600, Eric Blake wrote:
> On 01/23/2018 11:39 PM, Peter Xu wrote:
> > 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 }
> 
> Shouldn't this be '*allow-oob': true, as the only time you add the field is
> if you turn oob on (as it already defaults to off)?
> 
> >   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
> 
> s/to support/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": { } }
> 
> This talks more about the QMP user protocol, while the rest of the document
> is about QAPI constructs.  But we do have an example of 'my-first-command'
> in the document, so I guess this is okay.
> 
> > +
> > +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 ---
> 
> Do we really need the paragraph mentioning a forward reference, when the
> very next thing is the item that was referenced?

Yeah, I can remove that paragraph.

For all the rest of comments (above or below, which I omitted), all of
them make sense, and I'll fix accordingly.  Thanks for reviewing.

-- 
Peter Xu