[Qemu-devel] RFC: async commands with QMP

[Marc-André Lureau]

Hi

It seems there is no support for async commands with QAPI/QMP other
than having to poll for status, or a "sync" command followed
eventually by an event. But, there is no direct relation between the
command and the event.

As a monitor command shouldn't block, it would be useful to have async
commands support, if possible with a common scheme.

Here is a simple proposal, let's take an existing command:

                -> { "execute": "drive-backup", "arguments": {
"device": "drive0",
                                                               "sync": "full",

"target": "backup.img" },
                      "id": 1234 }
                <- { "return": {}, "id": 1234 }


You can then check regularly the state with query-block-jobs.. Suppose
instead of returning immediately, a similar function would return when
the task is completed. It would be nice if you wouldn't have to
duplicate existing blocking functions to an _async variant. Could we
introduce an additional "async" member? (rightfully rejected on qemu
today)

                -> { "execute": "drive-backup", "arguments": {
"device": "drive0",
                                                               "sync": "full",

"target": "backup.img" },
                      "id": 1234,
                      "async": true }
Here, with "async": true, the caller knows he shouldn't expect an
immediate return, and he can exchange other messages:
                -> { "execute"...
                <- { "event", ...
And when "drive-backup" finishes:
                <- { "return": {}, "id": 1234 }

In order to make "async" variant possible, "id" would have to be
provided and unique. I think the async support should also be
announced in the qmp_capabilities. Commands would have to opt-in for
async support in the schema. An async return wouldn't be allowed when
a blocking command is ongoing.

There are many variations possible on the same idea. We could
introduce new _async functions instead, and keep the "id"
requirements. Or alternatively, an "async_id" could be generated by
qemu and returned immediately. Then the reply of the command could be
an event instead. Ex:

                -> { "execute": "drive-backup-async", "arguments": {
"device": "drive0",
                                                               "sync": "full",

"target": "backup.img" },
                      "id": 1234 }
                <- { "return-async": {}, "async_id": 42 }
... later on:
                <- {"event": "ASYNC_COMPLETED", "async_id": 42,
"data": {.return values could go there..}, "id" 1234}

I haven't looked much on the implementation side, but I can try to
implement a proof-of-concept. Let see if this threads brings some
discussion first.

cheers

-- 
Marc-André Lureau