[Qemu-devel] [multiprocess RFC PATCH 00/37] Initial support of multi-process qemu

[Qemu-devel] [multiprocess RFC PATCH 00/37] Initial support of multi-process qemu

[elena.ufimtseva]

From: Elena Ufimtseva <elena.ufimtseva@oracle.com>

Initial support of multi-process qemu

CCing people who were discussing this functionality with Jag
during KVM forum last (2018) year to continue the conversation.

Started with the presentation in October 2017 made by
Marc-Andre (Red Hat) and Konrad Wilk (Oracle)
(http://events17.linuxfoundation.org/sites/events/files/slides/KVM%20FORUM%20multi-process.pdf,
https://www.youtube.com/watch?v=Kq1-coHh7lg) and
continued in the BoF session at the KVM forum in 2018 with Jag leading
the discussion, the multi-process project is now in the prototype version
and presented by this patchset.

The proof of the concept patches were posted on the qemu-devel mailing
list before the BoF session at the KVM forum and can be found here:
https://www.mail-archive.com/qemu-devel@nongnu.org/msg566538.html

This series presents the initial support for QEMU that can
launch some of the devices in the remote processes.

We would like to present set of RFC patches with some extention to the previous
patches and hoping that we can continue working on the patches with the community
feedback. Following people contributed to this patchset:

John G Johnson <john.g.johnson@oracle.com>
Jagannathan Raman <jag.raman@oracle.com>
Elena Ufimtseva <elena.ufimtseva@oracle.com>
Kanth Ghatraju <kanth.ghatraju@oracle.com>

Great QEMU code is the result of the efforts of many excellent
contributors and Coverity (static-analyzer) shows defect density
lower than in Linux kernel!
>From a security perspective, this is fantastic.
But as we all know new features and sometimes even bug-fixes
can bring in security bugs. We want to squash
them as soon as possible. Also, some of the older code may still
have security bugs lurking in it that haven't yet been explored.
Hence this patch set aims at minimizing the attack vectors
by splitting and minimizing the size of the text _without_
losing the wealth of features.
Being able to launch separate processes for emulation of
certain subsystems allow for providing for each remote process
only the privileges it needs to provide its service,
e.g., a disk service could be given access only the the
disk images it provides, and not be allowed to access other
files, or any network devices.
An attacker who compromised this service would not be able
to use this exploit to access files or devices beyond what
the disk service was given access to.

For full concept writeup about QEMU disaggregation refer to
docs/devel/qemu-multiprocess.txt.

This series has a limited scope and allows QEMU to launch
LSI SCSI controller emulation in the separate process and
execute HMP commands to manipulate the devices.

Please refer to the docs/qemu-multiprocess.txt for usage
information.

This series is based on qemu upstream (on top of the commit
commit 32694e98b8d7a246345448a8f707d2e11d6c65e2).

In the future we hope to work on:
  - live migration;
  - performance improvements;
  - support for more devices;
  - support for CPU disaggregated emulation;

We would like to welcome all your ideas, concerns and questions
for this patchset.

Thank you!

Elena Ufimtseva (15):
  multi-process: add a command line option for debug file
  multi-process: introduce proxy object
  multi-process: store info about the remote process
  multi-process: add command line options rdrive and rdevice
  multi-process: pass proxy link socket fd to remote process
  multi-process: configure remote side devices
  multi-process: add qdev_proxy_add to create proxy devices
  multi-process: remote: add setup_devices and setup_drive msg
    processing
  multi-process: remote: use fd for socket from parent process
  multi-process: remote: add create_done condition
  multi-process: add processing of rdrive and rdevice command line
  multi-process: add heartbeat timer and signal handler
  multi-process: handle heartbit messages in remote process
  multi-process: add the concept description to
    docs/devel/qemu-multiprocess
  multi-process: add configure and usage information

Jagannathan Raman (22):
  multi-process: memory: alloc RAM from file at offset
  multi-process: util: Add qemu_thread_cancel() to cancel running thread
  multi-process: Add stub functions to facilate build of multi-process
  multi-process: Add config option for multi-process QEMU
  multi-process: build system for remote device process
  multi-process: define proxy-link object
  multi-process: add functions to synchronize proxy and remote endpoints
  multi-process: setup PCI host bridge for remote device
  multi-process: setup a machine object for remote device process
  multi-process: setup memory manager for remote device
  multi-process: remote process initialization
  multi-process: PCI BAR write handling for proxy & remote endpoints
  multi-process: PCI BAR read handling for proxy & remote endpoints
  multi-process: Add LSI device proxy object
  multi-process: Synchronize remote memory
  multi-process: create IOHUB object to handle irq
  multi-process: Add QMP & HMP commands to list remote processes
  multi-process: QMP/HMP commands to add a device to the remote process
  multi-process: QMP/HMP commands to remove device from the remote
    process
  multi-process: HMP command to add drive to the remote device
  multi-process: HMP command to delete drive from remote device
  multi-process: QMP/HMP commands to resize block device on remote
    process

 Makefile                            |    5 +-
 Makefile.objs                       |   22 +
 Makefile.target                     |   53 +-
 accel/stubs/kvm-stub.c              |    5 +
 accel/stubs/tcg-stub.c              |   85 +++
 backends/Makefile.objs              |    2 +
 block/Makefile.objs                 |    2 +
 blockdev.c                          |   12 +
 configure                           |   11 +
 docs/devel/qemu-multiprocess.txt    | 1109 +++++++++++++++++++++++++++++++++++
 docs/qemu-multiprocess.txt          |  104 ++++
 exec.c                              |   12 +-
 hmp-commands.hx                     |   88 +++
 hmp.h                               |    4 +
 hw/Makefile.objs                    |    9 +
 hw/block/Makefile.objs              |    2 +
 hw/core/Makefile.objs               |   14 +
 hw/i386/pc.c                        |    1 +
 hw/nvram/Makefile.objs              |    2 +
 hw/pci/Makefile.objs                |    4 +
 hw/proxy/Makefile.objs              |    3 +
 hw/proxy/memory-sync.c              |  214 +++++++
 hw/proxy/monitor.c                  |  338 +++++++++++
 hw/proxy/proxy-lsi53c895a.c         |  162 +++++
 hw/proxy/qemu-proxy.c               |  461 +++++++++++++++
 hw/scsi/Makefile.objs               |    2 +
 include/exec/address-spaces.h       |    2 +
 include/exec/ram_addr.h             |    2 +-
 include/glib-compat.h               |    4 +
 include/hw/i386/pc.h                |    3 +
 include/hw/pci/pci_ids.h            |    3 +
 include/hw/proxy/memory-sync.h      |   51 ++
 include/hw/proxy/proxy-lsi53c895a.h |   42 ++
 include/hw/proxy/qemu-proxy.h       |   90 +++
 include/hw/qdev-core.h              |    1 +
 include/io/proxy-link.h             |  189 ++++++
 include/monitor/qdev.h              |    9 +
 include/qemu/log.h                  |    1 +
 include/qemu/mmap-alloc.h           |    2 +-
 include/qemu/thread.h               |    1 +
 include/remote/iohub.h              |   63 ++
 include/remote/machine.h            |   48 ++
 include/remote/memory.h             |   34 ++
 include/remote/pcihost.h            |   58 ++
 include/sysemu/blockdev.h           |    1 +
 include/sysemu/sysemu.h             |    3 +
 io/Makefile.objs                    |    2 +
 io/proxy-link.c                     |  301 ++++++++++
 memory.c                            |    2 +-
 migration/Makefile.objs             |    2 +
 monitor.c                           |    7 +
 qapi/block-core.json                |   54 ++
 qapi/misc.json                      |   49 ++
 qdev-monitor.c                      |  170 +++++-
 qemu-options.hx                     |   26 +
 qom/Makefile.objs                   |    4 +
 remote/Makefile.objs                |    4 +
 remote/iohub.c                      |  159 +++++
 remote/machine.c                    |  141 +++++
 remote/memory.c                     |   98 ++++
 remote/pcihost.c                    |   84 +++
 remote/remote-main.c                |  585 ++++++++++++++++++
 stubs/machine-init-done.c           |    4 +
 stubs/monitor.c                     |   25 +
 stubs/net-stub.c                    |   31 +
 stubs/replay.c                      |   14 +
 stubs/vl-stub.c                     |   75 +++
 stubs/vmstate.c                     |   20 +
 stubs/xen-mapcache.c                |   22 +
 util/log.c                          |    2 +
 util/mmap-alloc.c                   |    5 +-
 util/oslib-posix.c                  |    2 +-
 util/qemu-thread-posix.c            |   10 +
 vl.c                                |   76 +++
 74 files changed, 5291 insertions(+), 16 deletions(-)
 create mode 100644 docs/devel/qemu-multiprocess.txt
 create mode 100644 docs/qemu-multiprocess.txt
 create mode 100644 hw/proxy/Makefile.objs
 create mode 100644 hw/proxy/memory-sync.c
 create mode 100644 hw/proxy/monitor.c
 create mode 100644 hw/proxy/proxy-lsi53c895a.c
 create mode 100644 hw/proxy/qemu-proxy.c
 create mode 100644 include/hw/proxy/memory-sync.h
 create mode 100644 include/hw/proxy/proxy-lsi53c895a.h
 create mode 100644 include/hw/proxy/qemu-proxy.h
 create mode 100644 include/io/proxy-link.h
 create mode 100644 include/remote/iohub.h
 create mode 100644 include/remote/machine.h
 create mode 100644 include/remote/memory.h
 create mode 100644 include/remote/pcihost.h
 create mode 100644 io/proxy-link.c
 create mode 100644 remote/Makefile.objs
 create mode 100644 remote/iohub.c
 create mode 100644 remote/machine.c
 create mode 100644 remote/memory.c
 create mode 100644 remote/pcihost.c
 create mode 100644 remote/remote-main.c
 create mode 100644 stubs/net-stub.c
 create mode 100644 stubs/vl-stub.c
 create mode 100644 stubs/xen-mapcache.c

-- 
1.8.3.1

[Qemu-devel] [multiprocess RFC PATCH 35/37] multi-process: QMP/HMP commands to resize block device on remote process

[elena.ufimtseva]

From: Jagannathan Raman <jag.raman@oracle.com>

Adds rblock_resize QMP/HMP commands to resize block devices on the remote
process.

Signed-off-by: John G Johnson <john.g.johnson@oracle.com>
Signed-off-by: Jagannathan Raman <jag.raman@oracle.com>
Signed-off-by: Elena Ufimtseva <elena.ufimtseva@oracle.com>
---
 hmp-commands.hx         | 14 +++++++++++++
 hmp.h                   |  1 +
 hw/proxy/monitor.c      | 53 +++++++++++++++++++++++++++++++++++++++++++++++++
 include/io/proxy-link.h |  2 ++
 qapi/block-core.json    | 25 +++++++++++++++++++++++
 remote/remote-main.c    | 36 +++++++++++++++++++++++++++++++++
 6 files changed, 131 insertions(+)

diff --git a/hmp-commands.hx b/hmp-commands.hx
index 510fc24..844acd0 100644
--- a/hmp-commands.hx
+++ b/hmp-commands.hx
@@ -1429,6 +1429,20 @@ STEXI
 @findex rdrive_del
 Remove drive from remote PCI storage controller
 ETEXI
+
+    {
+        .name       = "rblock_resize",
+        .args_type  = "rdev_id:s,device:s,size:o",
+        .params     = "rdev_id device size",
+        .help       = "resize block device on the remote device",
+        .cmd        = hmp_rblock_resize,
+    },
+
+STEXI
+@item rblock_resize
+@findex rblock_resize
+Resize block device on the remote device
+ETEXI
 #endif
 
     {
diff --git a/hmp.h b/hmp.h
index 52b83c0..6a51bd3 100644
--- a/hmp.h
+++ b/hmp.h
@@ -152,5 +152,6 @@ void hmp_info_sev(Monitor *mon, const QDict *qdict);
 void hmp_remote_proc_list(Monitor *mon, const QDict *qdict);
 void hmp_rdevice_add(Monitor *mon, const QDict *qdict);
 void hmp_rdevice_del(Monitor *mon, const QDict *qdict);
+void hmp_rblock_resize(Monitor *mon, const QDict *qdict);
 
 #endif
diff --git a/hw/proxy/monitor.c b/hw/proxy/monitor.c
index aa09ea8..bd5fc4f 100644
--- a/hw/proxy/monitor.c
+++ b/hw/proxy/monitor.c
@@ -283,3 +283,56 @@ void hmp_rdrive_del(Monitor *mon, const QDict *qdict)
     (void)g_hash_table_remove(pcms->remote_devs, (gpointer)id);
 }
 
+void qmp_rblock_resize(const char *rdev_id, const char *device, int64_t size,
+                       Error **errp)
+{
+    PCMachineState *pcms = PC_MACHINE(current_machine);
+    PCIProxyDev *pdev = NULL;
+    ProcMsg msg = {0};
+    QString *json;
+    QDict *qdict;
+    int wait;
+
+    pdev = (PCIProxyDev *)g_hash_table_lookup(pcms->remote_devs, rdev_id);
+    if (!pdev) {
+        error_setg(errp, "No remote device named %s", device);
+        return;
+    }
+
+    qdict = qdict_new();
+    qdict_put_str(qdict, "device", device);
+    qdict_put_int(qdict, "size", size);
+
+    json = qobject_to_json(QOBJECT(qdict));
+
+    wait = GET_REMOTE_WAIT;
+
+    msg.cmd = BLOCK_RESIZE;
+    msg.bytestream = 1;
+    msg.size = strlen(qstring_get_str(json));
+    msg.data2 = (uint8_t *)qstring_get_str(json);
+    msg.num_fds = 1;
+    msg.fds[0] = wait;
+
+    proxy_proc_send(pdev->proxy_link, &msg);
+    (void)wait_for_remote(wait);
+    PUT_REMOTE_WAIT(wait);
+}
+
+void hmp_rblock_resize(Monitor *mon, const QDict *qdict)
+{
+    Error *local_err = NULL;
+    const char *rdev_id, *device;
+    int64_t size;
+
+    rdev_id = qdict_get_str(qdict, "rdev_id");
+    device = qdict_get_str(qdict, "device");
+    size = qdict_get_int(qdict, "size");
+
+    qmp_rblock_resize(rdev_id, device, size, &local_err);
+    if (local_err) {
+        monitor_printf(mon, "rblock_resize error: %s\n",
+                       error_get_pretty(local_err));
+        error_free(local_err);
+    }
+}
diff --git a/include/io/proxy-link.h b/include/io/proxy-link.h
index 013a845..8ed520c 100644
--- a/include/io/proxy-link.h
+++ b/include/io/proxy-link.h
@@ -64,6 +64,7 @@ typedef struct ProxyLinkState ProxyLinkState;
  * DEVICE_DEL       QMP/HMP command to hot-unplug device
  * DRIVE_ADD        HMP command to hotplug drive
  * DRIVE_DEL        HMP command to hot-unplug drive
+ * BLOCK_RESIZE     QMP/HMP command to resize block backend
  *
  */
 typedef enum {
@@ -81,6 +82,7 @@ typedef enum {
     DRIVE_ADD,
     DRIVE_DEL,
     PROXY_PING,
+    BLOCK_RESIZE,
     MAX,
 } proc_cmd_t;
 
diff --git a/qapi/block-core.json b/qapi/block-core.json
index 05394c4..4869ff7 100644
--- a/qapi/block-core.json
+++ b/qapi/block-core.json
@@ -1260,6 +1260,31 @@
             'size': 'int' } }
 
 ##
+# @rblock_resize:
+#
+# Resize a block image while a guest is running, on a remote device.
+#
+# @device: the name of the device to get the image resized
+#
+# @size:  new image size in bytes
+#
+# Returns: nothing on success
+#          If @device is not a valid block device, DeviceNotFound
+#
+# Since: 3.0.93
+#
+# Example:
+#
+# -> { "execute": "rblock_resize",
+#      "arguments": { "device": "scratch", "size": 1073741824 } }
+# <- { "return": {} }
+#
+##
+{ 'command': 'rblock_resize',
+  'data': { 'rdev_id': 'str', 'device': 'str', 'size': 'int' },
+  'if': 'defined(CONFIG_MPQEMU)' }
+
+##
 # @NewImageMode:
 #
 # An enumeration that tells QEMU how to set the backing file path in
diff --git a/remote/remote-main.c b/remote/remote-main.c
index 08e3528..3316546 100644
--- a/remote/remote-main.c
+++ b/remote/remote-main.c
@@ -64,6 +64,7 @@
 #include "qapi/qmp/qlist.h"
 #include "qemu/log.h"
 #include "qemu/cutils.h"
+#include "qapi/qapi-commands-block-core.h"
 
 static ProxyLinkState *proxy_link;
 PCIDevice *remote_pci_dev;
@@ -272,6 +273,38 @@ static void process_drive_del_msg(ProcMsg *msg)
     PUT_REMOTE_WAIT(wait);
 }
 
+static void process_block_resize_msg(ProcMsg *msg)
+{
+    const char *json = (const char *)msg->data2;
+    Error *local_err = NULL;
+    int wait = msg->fds[0];
+    const char *device;
+    int64_t size;
+    QObject *qobj = NULL;
+    QDict *qdict = NULL;
+
+    qobj = qobject_from_json(json, &local_err);
+    if (local_err) {
+        error_report_err(local_err);
+        return;
+    }
+
+    qdict = qobject_to(QDict, qobj);
+    assert(qdict);
+
+    device = qdict_get_str(qdict, "device");
+    size = qdict_get_int(qdict, "size");
+
+    qmp_block_resize(true, device, false, NULL, size, &local_err);
+    if (local_err) {
+        error_report_err(local_err);
+    }
+
+    notify_proxy(wait, 1);
+
+    PUT_REMOTE_WAIT(wait);
+}
+
 static int init_drive(QDict *rqdict, Error **errp)
 {
     QemuOpts *opts;
@@ -468,6 +501,9 @@ static void process_msg(GIOCondition cond)
         notify_proxy(wait, (uint32_t)getpid());
         PUT_REMOTE_WAIT(wait);
         break;
+    case BLOCK_RESIZE:
+        process_block_resize_msg(msg);
+        break;
     default:
         error_setg(&err, "Unknown command");
         goto finalize_loop;
-- 
1.8.3.1

Re: [Qemu-devel] [multiprocess RFC PATCH 00/37] Initial support of multi-process qemu

[Stefan Hajnoczi]

[-- Attachment #1: Type: text/plain, Size: 516 bytes --]

On Wed, Mar 06, 2019 at 11:20:25PM -0800, elena.ufimtseva@oracle.com wrote:
> From: Elena Ufimtseva <elena.ufimtseva@oracle.com>
> 
> Initial support of multi-process qemu

Hi Elena,
Please use the following setting when sending future patch series:

  $ git config sendemail.thread shallow

This way all patches are part of a single email thread (starting with
your PATCH 00 cover letter).  Reviewers find this more convenient so
that individual emails don't get separated and lost.

Thanks,
Stefan

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 455 bytes --]

Re: [Qemu-devel] [multiprocess RFC PATCH 00/37] Initial support of multi-process qemu

[Marc-André Lureau]

Hi

On Thu, Mar 7, 2019 at 11:46 AM Stefan Hajnoczi <stefanha@gmail.com> wrote:
>
> On Wed, Mar 06, 2019 at 11:20:25PM -0800, elena.ufimtseva@oracle.com wrote:
> > From: Elena Ufimtseva <elena.ufimtseva@oracle.com>
> >
> > Initial support of multi-process qemu
>
> Hi Elena,
> Please use the following setting when sending future patch series:
>
>   $ git config sendemail.thread shallow
>
> This way all patches are part of a single email thread (starting with
> your PATCH 00 cover letter).  Reviewers find this more convenient so
> that individual emails don't get separated and lost.
>

Please also check that there is no regression after each commit. In
particular, the build shouldn't fail, so we can easily study, apply
and bisect patches one by one.

thanks


-- 
Marc-André Lureau

Re: [Qemu-devel] [multiprocess RFC PATCH 35/37] multi-process: QMP/HMP commands to resize block device on remote process

[Kevin Wolf]

Am 07.03.2019 um 08:22 hat elena.ufimtseva@oracle.com geschrieben:
> From: Jagannathan Raman <jag.raman@oracle.com>
> 
> Adds rblock_resize QMP/HMP commands to resize block devices on the remote
> process.
> 
> Signed-off-by: John G Johnson <john.g.johnson@oracle.com>
> Signed-off-by: Jagannathan Raman <jag.raman@oracle.com>
> Signed-off-by: Elena Ufimtseva <elena.ufimtseva@oracle.com>

Up to this patch, I thought that maybe the block layer related things
would only need a few changes, like:

* Have -rblockdev instead of -rdrive
* Add QMP version for HMP-only only commands

But this one got me thinking. If I understand this correctly, the
current design means that we have to duplicate every single QMP command
to have a remote variant. This just doesn't scale.

I'm not entirely sure what the final design should look like, but I
think we need to have a separate QMP connection to the process that owns
the block device so that the normal existing QMP commands can be used to
managed it.

In the long run, I think you'll want to separate the block backends from
the device emulation anyway. The thing I have in mind is the storage
daemon idea that was occasionally mentioned here and there; and the
process that owns the device would connect to the backend process, maybe
using the vhost-user protocol (or an extension of it with more
management stuff). For the start, that separate process could in fact be
the main process.

For a limited prototype, maybe we could even use NBD, which is already
existing (both server and client parts), but will obviously impact
performance. Then we'd need a way to configure the remote device process
to connect to either an external NBD server (e.g. qemu-nbd) or to the
main process, which would manage the real storage and export it to the
remote processes over NBD.

In a second step, we could switch it over to a different protocol that
is more feature complete and can provide better performance.

This probably needs some more thought, but what do you think in general?

Kevin

Re: [Qemu-devel] [multiprocess RFC PATCH 35/37] multi-process: QMP/HMP commands to resize block device on remote process

[Dr. David Alan Gilbert]

* Kevin Wolf (kwolf@redhat.com) wrote:
> Am 07.03.2019 um 08:22 hat elena.ufimtseva@oracle.com geschrieben:
> > From: Jagannathan Raman <jag.raman@oracle.com>
> > 
> > Adds rblock_resize QMP/HMP commands to resize block devices on the remote
> > process.
> > 
> > Signed-off-by: John G Johnson <john.g.johnson@oracle.com>
> > Signed-off-by: Jagannathan Raman <jag.raman@oracle.com>
> > Signed-off-by: Elena Ufimtseva <elena.ufimtseva@oracle.com>
> 
> Up to this patch, I thought that maybe the block layer related things
> would only need a few changes, like:
> 
> * Have -rblockdev instead of -rdrive
> * Add QMP version for HMP-only only commands
> 
> But this one got me thinking. If I understand this correctly, the
> current design means that we have to duplicate every single QMP command
> to have a remote variant. This just doesn't scale.
> 
> I'm not entirely sure what the final design should look like, but I
> think we need to have a separate QMP connection to the process that owns
> the block device so that the normal existing QMP commands can be used to
> managed it.
> 
> In the long run, I think you'll want to separate the block backends from
> the device emulation anyway. The thing I have in mind is the storage
> daemon idea that was occasionally mentioned here and there; and the
> process that owns the device would connect to the backend process, maybe
> using the vhost-user protocol (or an extension of it with more
> management stuff). For the start, that separate process could in fact be
> the main process.
> 
> For a limited prototype, maybe we could even use NBD, which is already
> existing (both server and client parts), but will obviously impact
> performance. Then we'd need a way to configure the remote device process
> to connect to either an external NBD server (e.g. qemu-nbd) or to the
> main process, which would manage the real storage and export it to the
> remote processes over NBD.
> 
> In a second step, we could switch it over to a different protocol that
> is more feature complete and can provide better performance.
> 
> This probably needs some more thought, but what do you think in general?

Yeh I was noticing something similar; in a way it feels like you
should be able to do something like make this a property of a bus - i.e.
adding a drive to the bus that's on the remote controller routes it over
to the remote process rather than needing a special command.

Dave

> Kevin
--
Dr. David Alan Gilbert / dgilbert@redhat.com / Manchester, UK

Re: [Qemu-devel] [multiprocess RFC PATCH 35/37] multi-process: QMP/HMP commands to resize block device on remote process

[Eric Blake]

[-- Attachment #1: Type: text/plain, Size: 1255 bytes --]

On 3/7/19 1:22 AM, elena.ufimtseva@oracle.com wrote:
> From: Jagannathan Raman <jag.raman@oracle.com>
> 
> Adds rblock_resize QMP/HMP commands to resize block devices on the remote
> process.
> 
> Signed-off-by: John G Johnson <john.g.johnson@oracle.com>
> Signed-off-by: Jagannathan Raman <jag.raman@oracle.com>
> Signed-off-by: Elena Ufimtseva <elena.ufimtseva@oracle.com>
> ---

I know the discussion is questioning whether this is even the right way
to go, but if we DO add a QMP command,

> +++ b/qapi/block-core.json
> @@ -1260,6 +1260,31 @@
>              'size': 'int' } }
>  
>  ##
> +# @rblock_resize:

It should be named 'rblock-resize'

> +#
> +# Resize a block image while a guest is running, on a remote device.
> +#
> +# @device: the name of the device to get the image resized
> +#
> +# @size:  new image size in bytes
> +#
> +# Returns: nothing on success
> +#          If @device is not a valid block device, DeviceNotFound
> +#
> +# Since: 3.0.93

and you've missed 3.0 (if you got it in THIS week, it would be Since
4.0; but that's unlikely, so you want Since 4.1).

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


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: [Qemu-devel] [multiprocess RFC PATCH 00/37] Initial support of multi-process qemu

[Elena Ufimtseva]

On Thu, Mar 07, 2019 at 02:27:57PM +0100, Marc-André Lureau wrote:
> Hi
> 
> On Thu, Mar 7, 2019 at 11:46 AM Stefan Hajnoczi <stefanha@gmail.com> wrote:
> >
> > On Wed, Mar 06, 2019 at 11:20:25PM -0800, elena.ufimtseva@oracle.com wrote:
> > > From: Elena Ufimtseva <elena.ufimtseva@oracle.com>
> > >
> > > Initial support of multi-process qemu
> >
> > Hi Elena,
> > Please use the following setting when sending future patch series:
> >
> >   $ git config sendemail.thread shallow
> >
> > This way all patches are part of a single email thread (starting with
> > your PATCH 00 cover letter).  Reviewers find this more convenient so
> > that individual emails don't get separated and lost.

Thanks Stefan, will do.
> >
> 
> Please also check that there is no regression after each commit. In
> particular, the build shouldn't fail, so we can easily study, apply
> and bisect patches one by one.
> 


Yep, we try to make sure each commit builds and will automate for future
series as well, maybe with some simple tests.

Elena

> thanks
> 
> 
> -- 
> Marc-André Lureau