From nobody Sun Feb 8 21:28:52 2026 Delivered-To: importer@patchew.org Received-SPF: pass (zoho.com: domain of gnu.org designates 208.118.235.17 as permitted sender) client-ip=208.118.235.17; envelope-from=qemu-devel-bounces+importer=patchew.org@nongnu.org; helo=lists.gnu.org; Authentication-Results: mx.zohomail.com; spf=pass (zoho.com: domain of gnu.org designates 208.118.235.17 as permitted sender) smtp.mailfrom=qemu-devel-bounces+importer=patchew.org@nongnu.org; dmarc=fail(p=none dis=none) header.from=redhat.com Return-Path: Received: from lists.gnu.org (lists.gnu.org [208.118.235.17]) by mx.zohomail.com with SMTPS id 1520586191331797.5186083891008; Fri, 9 Mar 2018 01:03:11 -0800 (PST) Received: from localhost ([::1]:43871 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1euDvi-0000aV-Ib for importer@patchew.org; Fri, 09 Mar 2018 04:03:10 -0500 Received: from eggs.gnu.org ([2001:4830:134:3::10]:41509) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1euDt6-0007Z3-IP for qemu-devel@nongnu.org; Fri, 09 Mar 2018 04:00:33 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1euDt1-0007im-1f for qemu-devel@nongnu.org; Fri, 09 Mar 2018 04:00:28 -0500 Received: from mx3-rdu2.redhat.com ([66.187.233.73]:58804 helo=mx1.redhat.com) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1euDt0-0007id-Rr for qemu-devel@nongnu.org; Fri, 09 Mar 2018 04:00:22 -0500 Received: from smtp.corp.redhat.com (int-mx04.intmail.prod.int.rdu2.redhat.com [10.11.54.4]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 642D7406805B; Fri, 9 Mar 2018 09:00:21 +0000 (UTC) Received: from xz-mi.redhat.com (ovpn-12-92.pek2.redhat.com [10.72.12.92]) by smtp.corp.redhat.com (Postfix) with ESMTP id 0FFAA202322A; Fri, 9 Mar 2018 09:00:16 +0000 (UTC) From: Peter Xu To: qemu-devel@nongnu.org Date: Fri, 9 Mar 2018 16:59:44 +0800 Message-Id: <20180309090006.10018-2-peterx@redhat.com> In-Reply-To: <20180309090006.10018-1-peterx@redhat.com> References: <20180309090006.10018-1-peterx@redhat.com> X-Scanned-By: MIMEDefang 2.78 on 10.11.54.4 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.11.55.5]); Fri, 09 Mar 2018 09:00:21 +0000 (UTC) X-Greylist: inspected by milter-greylist-4.5.16 (mx1.redhat.com [10.11.55.5]); Fri, 09 Mar 2018 09:00:21 +0000 (UTC) for IP:'10.11.54.4' DOMAIN:'int-mx04.intmail.prod.int.rdu2.redhat.com' HELO:'smtp.corp.redhat.com' FROM:'peterx@redhat.com' RCPT:'' X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] [fuzzy] X-Received-From: 66.187.233.73 Subject: [Qemu-devel] [PATCH v8 01/23] docs: update QMP documents for OOB commands X-BeenThere: qemu-devel@nongnu.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Laurent Vivier , Fam Zheng , Juan Quintela , mdroth@linux.vnet.ibm.com, peterx@redhat.com, Markus Armbruster , marcandre.lureau@redhat.com, Stefan Hajnoczi , Paolo Bonzini , "Dr . David Alan Gilbert" Errors-To: qemu-devel-bounces+importer=patchew.org@nongnu.org Sender: "Qemu-devel" X-ZohoMail: RSF_0 Z_629925259 SPT_0 Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Update both the developer and spec for the new QMP OOB (Out-Of-Band) command. Signed-off-by: Peter Xu Reviewed-by: Eric Blake --- 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: =20 =3D=3D=3D Commands =3D=3D=3D =20 +--- 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 } =20 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 op= tional key 'success-response' with boolean value false. So far, only QGA makes use of this member. =20 +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: + + =3D> { "execute": "command-support-oob", + "arguments": { ... }, + "control": { "run-oob": true } } + <=3D { "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. =20 =3D=3D=3D Events =3D=3D=3D =20 @@ -739,10 +792,12 @@ references by name. QAPI schema definitions not reachable that way are omitted. =20 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. =20 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 ------------------ =20 -As of the date this document was last revised, no server or client -capability strings have been defined. +Currently supported capabilities are: =20 +- "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. =20 2.3 Issuing Commands -------------------- =20 The format for command execution is: =20 -{ "execute": json-string, "arguments": json-object, "id": json-value } +{ "execute": json-string, "arguments": json-object, "id": json-value, + "control": json-dict } =20 Where, =20 @@ -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 } } =20 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. =20 +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 ------------- =20 --=20 2.14.3