[PULL 0/4] Block patches

[PULL 0/4] Block patches

[Stefan Hajnoczi]

The following changes since commit 560009f2c8b57b7cdd31a5693ea86ab369382f49:

  Merge remote-tracking branch 'remotes/kevin/tags/for-upstream' into staging (2019-10-07 15:40:53 +0100)

are available in the Git repository at:

  https://github.com/stefanha/qemu.git tags/block-pull-request

for you to fetch changes up to 4d804b5305ffb4d5fa414c38d4f1bdfb987c8d0b:

  iotests/262: Switch source/dest VM launch order (2019-10-08 14:28:25 +0100)

----------------------------------------------------------------
Pull request

This pull request also contains the two commits from the previous pull request
that was dropped due to a mingw compilation error.  The compilation should now
be fixed.

----------------------------------------------------------------

Max Reitz (2):
  block: Skip COR for inactive nodes
  iotests/262: Switch source/dest VM launch order

Sergio Lopez (1):
  virtio-blk: schedule virtio_notify_config to run on main context

Vladimir Sementsov-Ogievskiy (1):
  util/ioc.c: try to reassure Coverity about qemu_iovec_init_extended

 block/io.c                 | 41 +++++++++++++++++++++++++-------------
 hw/block/virtio-blk.c      | 16 ++++++++++++++-
 util/iov.c                 |  5 +++--
 tests/qemu-iotests/262     | 12 +++++------
 tests/qemu-iotests/262.out |  6 +++---
 5 files changed, 54 insertions(+), 26 deletions(-)

-- 
2.21.0

[PULL 1/4] util/ioc.c: try to reassure Coverity about qemu_iovec_init_extended

[Stefan Hajnoczi]

From: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com>

Make it more obvious, that filling qiov corresponds to qiov allocation,
which in turn corresponds to total_niov calculation, based on mid_niov
(not mid_len). Still add an assertion to show that there should be no
difference.

[Added mingw "error: 'mid_iov' may be used uninitialized in this
function" compiler error fix suggested by Vladimir.
--Stefan]

Reported-by: Coverity (CID 1405302)
Signed-off-by: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com>
Message-id: 20190910090310.14032-1-vsementsov@virtuozzo.com
Suggested-by: Peter Maydell <peter.maydell@linaro.org>
Signed-off-by: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com>
Message-Id: <20190910090310.14032-1-vsementsov@virtuozzo.com>
Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>

fixup! util/ioc.c: try to reassure Coverity about qemu_iovec_init_extended
---
 util/iov.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/util/iov.c b/util/iov.c
index 5059e10431..45ef3043ee 100644
--- a/util/iov.c
+++ b/util/iov.c
@@ -423,7 +423,7 @@ void qemu_iovec_init_extended(
 {
     size_t mid_head, mid_tail;
     int total_niov, mid_niov = 0;
-    struct iovec *p, *mid_iov;
+    struct iovec *p, *mid_iov = NULL;
 
     if (mid_len) {
         mid_iov = qiov_slice(mid_qiov, mid_offset, mid_len,
@@ -446,7 +446,8 @@ void qemu_iovec_init_extended(
         p++;
     }
 
-    if (mid_len) {
+    assert(!mid_niov == !mid_len);
+    if (mid_niov) {
         memcpy(p, mid_iov, mid_niov * sizeof(*p));
         p[0].iov_base = (uint8_t *)p[0].iov_base + mid_head;
         p[0].iov_len -= mid_head;
-- 
2.21.0

[PULL 2/4] virtio-blk: schedule virtio_notify_config to run on main context

[Stefan Hajnoczi]

From: Sergio Lopez <slp@redhat.com>

virtio_notify_config() needs to acquire the global mutex, which isn't
allowed from an iothread, and may lead to a deadlock like this:

 - main thead
  * Has acquired: qemu_global_mutex.
  * Is trying the acquire: iothread AioContext lock via
    AIO_WAIT_WHILE (after aio_poll).

 - iothread
  * Has acquired: AioContext lock.
  * Is trying to acquire: qemu_global_mutex (via
    virtio_notify_config->prepare_mmio_access).

If virtio_blk_resize() is called from an iothread, schedule
virtio_notify_config() to be run in the main context BH.

[Removed unnecessary newline as suggested by Kevin Wolf
<kwolf@redhat.com>.
--Stefan]

Signed-off-by: Sergio Lopez <slp@redhat.com>
Reviewed-by: Kevin Wolf <kwolf@redhat.com>
Message-id: 20190916112411.21636-1-slp@redhat.com
Message-Id: <20190916112411.21636-1-slp@redhat.com>
Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
---
 hw/block/virtio-blk.c | 16 +++++++++++++++-
 1 file changed, 15 insertions(+), 1 deletion(-)

diff --git a/hw/block/virtio-blk.c b/hw/block/virtio-blk.c
index 18851601cb..ed2ddebd2b 100644
--- a/hw/block/virtio-blk.c
+++ b/hw/block/virtio-blk.c
@@ -16,6 +16,7 @@
 #include "qemu/iov.h"
 #include "qemu/module.h"
 #include "qemu/error-report.h"
+#include "qemu/main-loop.h"
 #include "trace.h"
 #include "hw/block/block.h"
 #include "hw/qdev-properties.h"
@@ -1086,11 +1087,24 @@ static int virtio_blk_load_device(VirtIODevice *vdev, QEMUFile *f,
     return 0;
 }
 
+static void virtio_resize_cb(void *opaque)
+{
+    VirtIODevice *vdev = opaque;
+
+    assert(qemu_get_current_aio_context() == qemu_get_aio_context());
+    virtio_notify_config(vdev);
+}
+
 static void virtio_blk_resize(void *opaque)
 {
     VirtIODevice *vdev = VIRTIO_DEVICE(opaque);
 
-    virtio_notify_config(vdev);
+    /*
+     * virtio_notify_config() needs to acquire the global mutex,
+     * so it can't be called from an iothread. Instead, schedule
+     * it to be run in the main context BH.
+     */
+    aio_bh_schedule_oneshot(qemu_get_aio_context(), virtio_resize_cb, vdev);
 }
 
 static const BlockDevOps virtio_block_ops = {
-- 
2.21.0

[PULL 3/4] block: Skip COR for inactive nodes

[Stefan Hajnoczi]

From: Max Reitz <mreitz@redhat.com>

We must not write data to inactive nodes, and a COR is certainly
something we can simply not do without upsetting anyone.  So skip COR
operations on inactive nodes.

Signed-off-by: Max Reitz <mreitz@redhat.com>
Reviewed-by: Eric Blake <eblake@redhat.com>
Message-id: 20191001174827.11081-2-mreitz@redhat.com
Message-Id: <20191001174827.11081-2-mreitz@redhat.com>
Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
---
 block/io.c | 41 +++++++++++++++++++++++++++--------------
 1 file changed, 27 insertions(+), 14 deletions(-)

diff --git a/block/io.c b/block/io.c
index f8c3596131..4f9ee97c2b 100644
--- a/block/io.c
+++ b/block/io.c
@@ -1246,11 +1246,18 @@ static int coroutine_fn bdrv_co_do_copy_on_readv(BdrvChild *child,
     int max_transfer = MIN_NON_ZERO(bs->bl.max_transfer,
                                     BDRV_REQUEST_MAX_BYTES);
     unsigned int progress = 0;
+    bool skip_write;
 
     if (!drv) {
         return -ENOMEDIUM;
     }
 
+    /*
+     * Do not write anything when the BDS is inactive.  That is not
+     * allowed, and it would not help.
+     */
+    skip_write = (bs->open_flags & BDRV_O_INACTIVE);
+
     /* FIXME We cannot require callers to have write permissions when all they
      * are doing is a read request. If we did things right, write permissions
      * would be obtained anyway, but internally by the copy-on-read code. As
@@ -1274,23 +1281,29 @@ static int coroutine_fn bdrv_co_do_copy_on_readv(BdrvChild *child,
     while (cluster_bytes) {
         int64_t pnum;
 
-        ret = bdrv_is_allocated(bs, cluster_offset,
-                                MIN(cluster_bytes, max_transfer), &pnum);
-        if (ret < 0) {
-            /* Safe to treat errors in querying allocation as if
-             * unallocated; we'll probably fail again soon on the
-             * read, but at least that will set a decent errno.
-             */
+        if (skip_write) {
+            ret = 1; /* "already allocated", so nothing will be copied */
             pnum = MIN(cluster_bytes, max_transfer);
-        }
+        } else {
+            ret = bdrv_is_allocated(bs, cluster_offset,
+                                    MIN(cluster_bytes, max_transfer), &pnum);
+            if (ret < 0) {
+                /*
+                 * Safe to treat errors in querying allocation as if
+                 * unallocated; we'll probably fail again soon on the
+                 * read, but at least that will set a decent errno.
+                 */
+                pnum = MIN(cluster_bytes, max_transfer);
+            }
 
-        /* Stop at EOF if the image ends in the middle of the cluster */
-        if (ret == 0 && pnum == 0) {
-            assert(progress >= bytes);
-            break;
-        }
+            /* Stop at EOF if the image ends in the middle of the cluster */
+            if (ret == 0 && pnum == 0) {
+                assert(progress >= bytes);
+                break;
+            }
 
-        assert(skip_bytes < pnum);
+            assert(skip_bytes < pnum);
+        }
 
         if (ret <= 0) {
             QEMUIOVector local_qiov;
-- 
2.21.0

[PULL 4/4] iotests/262: Switch source/dest VM launch order

[Stefan Hajnoczi]

From: Max Reitz <mreitz@redhat.com>

Launching the destination VM before the source VM gives us a regression
test for HEAD^:

The guest device causes a read from the disk image through
guess_disk_lchs().  This will not work if the first sector (containing
the partition table) is yet unallocated, we use COR, and the node is
inactive.

By launching the source VM before the destination, however, the COR
filter on the source will allocate that area in the image shared between
both VMs, thus the problem will not become apparent.

Switching the launch order causes the sector to still be unallocated
when guess_disk_lchs() runs on the inactive node in the destination VM,
and thus we get our test case.

Signed-off-by: Max Reitz <mreitz@redhat.com>
Reviewed-by: Eric Blake <eblake@redhat.com>
Message-id: 20191001174827.11081-3-mreitz@redhat.com
Message-Id: <20191001174827.11081-3-mreitz@redhat.com>
Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
---
 tests/qemu-iotests/262     | 12 ++++++------
 tests/qemu-iotests/262.out |  6 +++---
 2 files changed, 9 insertions(+), 9 deletions(-)

diff --git a/tests/qemu-iotests/262 b/tests/qemu-iotests/262
index 398f63587e..0963daa806 100755
--- a/tests/qemu-iotests/262
+++ b/tests/qemu-iotests/262
@@ -54,12 +54,6 @@ with iotests.FilePath('img') as img_path, \
 
     os.mkfifo(fifo)
 
-    iotests.log('Launching source VM...')
-    add_opts(vm_a)
-    vm_a.launch()
-
-    vm_a.enable_migration_events('A')
-
     iotests.log('Launching destination VM...')
     add_opts(vm_b)
     vm_b.add_incoming("exec: cat '%s'" % (fifo))
@@ -67,6 +61,12 @@ with iotests.FilePath('img') as img_path, \
 
     vm_b.enable_migration_events('B')
 
+    iotests.log('Launching source VM...')
+    add_opts(vm_a)
+    vm_a.launch()
+
+    vm_a.enable_migration_events('A')
+
     iotests.log('Starting migration to B...')
     iotests.log(vm_a.qmp('migrate', uri='exec:cat >%s' % (fifo)))
     with iotests.Timeout(3, 'Migration does not complete'):
diff --git a/tests/qemu-iotests/262.out b/tests/qemu-iotests/262.out
index 5a58e5e9f8..8e04c496c4 100644
--- a/tests/qemu-iotests/262.out
+++ b/tests/qemu-iotests/262.out
@@ -1,9 +1,9 @@
-Launching source VM...
-Enabling migration QMP events on A...
-{"return": {}}
 Launching destination VM...
 Enabling migration QMP events on B...
 {"return": {}}
+Launching source VM...
+Enabling migration QMP events on A...
+{"return": {}}
 Starting migration to B...
 {"return": {}}
 {"data": {"status": "setup"}, "event": "MIGRATION", "timestamp": {"microseconds": "USECS", "seconds": "SECS"}}
-- 
2.21.0

Re: [PULL 0/4] Block patches

[Peter Maydell]

On Tue, 8 Oct 2019 at 15:55, Stefan Hajnoczi <stefanha@redhat.com> wrote:
>
> The following changes since commit 560009f2c8b57b7cdd31a5693ea86ab369382f49:
>
>   Merge remote-tracking branch 'remotes/kevin/tags/for-upstream' into staging (2019-10-07 15:40:53 +0100)
>
> are available in the Git repository at:
>
>   https://github.com/stefanha/qemu.git tags/block-pull-request
>
> for you to fetch changes up to 4d804b5305ffb4d5fa414c38d4f1bdfb987c8d0b:
>
>   iotests/262: Switch source/dest VM launch order (2019-10-08 14:28:25 +0100)
>
> ----------------------------------------------------------------
> Pull request
>
> This pull request also contains the two commits from the previous pull request
> that was dropped due to a mingw compilation error.  The compilation should now
> be fixed.
>
> ----------------------------------------------------------------
>


Applied, thanks.

Please update the changelog at https://wiki.qemu.org/ChangeLog/4.2
for any user-visible changes.

-- PMM

[PULL 0/4] Block patches

[Stefan Hajnoczi]

The following changes since commit 27c94566379069fb8930bb1433dcffbf7df3203d:

  Merge remote-tracking branch 'remotes/edgar/tags/edgar/xilinx-next-2020-04-30.for-upstream' into staging (2020-04-30 16:47:23 +0100)

are available in the Git repository at:

  https://github.com/stefanha/qemu.git tags/block-pull-request

for you to fetch changes up to cc1adc4488059ac16d4d2772a7aa7cd1323deeca:

  lockable: Replace locks with lock guard macros (2020-05-01 09:19:25 +0100)

----------------------------------------------------------------
Pull request

Fix the QEMU_LOCK_GUARD() macros, use them more widely, and allow the fuzzer
target to be selected from argv[0].

----------------------------------------------------------------

Alexander Bulekov (1):
  fuzz: select fuzz target using executable name

Daniel Brodsky (2):
  lockable: fix __COUNTER__ macro to be referenced properly
  lockable: replaced locks with lock guard macros where appropriate

Simran Singhal (1):
  lockable: Replace locks with lock guard macros

 include/qemu/lockable.h |  7 +++---
 include/qemu/rcu.h      |  2 +-
 block/iscsi.c           |  7 ++----
 block/nfs.c             | 51 +++++++++++++++++++----------------------
 cpus-common.c           | 14 ++++-------
 hw/display/qxl.c        | 43 ++++++++++++++++------------------
 hw/hyperv/hyperv.c      | 15 ++++++------
 hw/rdma/rdma_backend.c  | 50 ++++++++++++++++++++--------------------
 hw/rdma/rdma_rm.c       |  3 +--
 hw/vfio/platform.c      |  5 ++--
 migration/migration.c   |  3 +--
 migration/multifd.c     |  8 +++----
 migration/ram.c         |  3 +--
 monitor/misc.c          |  4 +---
 tests/qtest/fuzz/fuzz.c | 19 ++++++++-------
 ui/spice-display.c      | 14 +++++------
 util/log.c              |  4 ++--
 util/qemu-timer.c       | 17 +++++++-------
 util/rcu.c              |  8 +++----
 util/thread-pool.c      |  3 +--
 util/vfio-helpers.c     |  5 ++--
 slirp                   |  2 +-
 22 files changed, 133 insertions(+), 154 deletions(-)

-- 
2.25.3

Re: [PULL 0/4] Block patches

[no-reply]

Patchew URL: https://patchew.org/QEMU/20200501082806.205696-1-stefanha@redhat.com/



Hi,

This series failed the docker-quick@centos7 build test. Please find the testing commands and
their output below. If you have Docker installed, you can probably reproduce it
locally.

=== TEST SCRIPT BEGIN ===
#!/bin/bash
make docker-image-centos7 V=1 NETWORK=1
time make docker-test-quick@centos7 SHOW_ENV=1 J=14 NETWORK=1
=== TEST SCRIPT END ===

  TEST    iotest-qcow2: 074
socket_accept failed: Resource temporarily unavailable
**
ERROR:/tmp/qemu-test/src/tests/qtest/libqtest.c:301:qtest_init_without_qmp_handshake: assertion failed: (s->fd >= 0 && s->qmp_fd >= 0)
/tmp/qemu-test/src/tests/qtest/libqtest.c:166: kill_qemu() tried to terminate QEMU process but encountered exit status 1 (expected 0)
ERROR - Bail out! ERROR:/tmp/qemu-test/src/tests/qtest/libqtest.c:301:qtest_init_without_qmp_handshake: assertion failed: (s->fd >= 0 && s->qmp_fd >= 0)
make: *** [check-qtest-aarch64] Error 1
make: *** Waiting for unfinished jobs....
  TEST    iotest-qcow2: 079
  TEST    iotest-qcow2: 080
---
Not run: 259
Failures: 249
Failed 1 of 117 iotests
make: *** [check-tests/check-block.sh] Error 1
Traceback (most recent call last):
  File "./tests/docker/docker.py", line 664, in <module>
    sys.exit(main())
---
    raise CalledProcessError(retcode, cmd)
subprocess.CalledProcessError: Command '['sudo', '-n', 'docker', 'run', '--label', 'com.qemu.instance.uuid=57718c949eb54215807b45721021e7ee', '-u', '1003', '--security-opt', 'seccomp=unconfined', '--rm', '-e', 'TARGET_LIST=', '-e', 'EXTRA_CONFIGURE_OPTS=', '-e', 'V=', '-e', 'J=14', '-e', 'DEBUG=', '-e', 'SHOW_ENV=1', '-e', 'CCACHE_DIR=/var/tmp/ccache', '-v', '/home/patchew2/.cache/qemu-docker-ccache:/var/tmp/ccache:z', '-v', '/var/tmp/patchew-tester-tmp-kc_n7mcq/src/docker-src.2020-05-01-04.40.40.25959:/var/tmp/qemu:z,ro', 'qemu:centos7', '/var/tmp/qemu/run', 'test-quick']' returned non-zero exit status 2.
filter=--filter=label=com.qemu.instance.uuid=57718c949eb54215807b45721021e7ee
make[1]: *** [docker-run] Error 1
make[1]: Leaving directory `/var/tmp/patchew-tester-tmp-kc_n7mcq/src'
make: *** [docker-run-test-quick@centos7] Error 2

real    21m18.481s
user    0m10.757s


The full log is available at
http://patchew.org/logs/20200501082806.205696-1-stefanha@redhat.com/testing.docker-quick@centos7/?type=message.
---
Email generated automatically by Patchew [https://patchew.org/].
Please send your feedback to patchew-devel@redhat.com

Re: [PULL 0/4] Block patches

[Peter Maydell]

On Fri, 1 May 2020 at 09:28, Stefan Hajnoczi <stefanha@redhat.com> wrote:
>
> The following changes since commit 27c94566379069fb8930bb1433dcffbf7df3203d:
>
>   Merge remote-tracking branch 'remotes/edgar/tags/edgar/xilinx-next-2020-04-30.for-upstream' into staging (2020-04-30 16:47:23 +0100)
>
> are available in the Git repository at:
>
>   https://github.com/stefanha/qemu.git tags/block-pull-request
>
> for you to fetch changes up to cc1adc4488059ac16d4d2772a7aa7cd1323deeca:
>
>   lockable: Replace locks with lock guard macros (2020-05-01 09:19:25 +0100)
>
> ----------------------------------------------------------------
> Pull request
>
> Fix the QEMU_LOCK_GUARD() macros, use them more widely, and allow the fuzzer
> target to be selected from argv[0].
>
> ----------------------------------------------------------------

Hi; this pullreq seems to include a stray change to the slirp
submodule in the "fuzz: select fuzz target using executable name"
commit. Could you fix that and resend, please?

(You might like to include a molly-guard in your pullreq
creation scripts; on my end I catch this sort of thing
when applying with a test like
if git diff master..staging | grep -q 'Subproject commit'; then
    # complain and exit unless I used an explicit command
    # line option to say I intended to include a submodule update
fi

though I haven't yet put the same test in the script I use
to send pullreqs, for some reason. I guess my workflow now
means I don't tend to accidentally commit submodule changes.)

thanks
-- PMM

Re: [PULL 0/4] Block patches

[Stefan Hajnoczi]

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

On Fri, May 01, 2020 at 10:32:02AM +0100, Peter Maydell wrote:
> On Fri, 1 May 2020 at 09:28, Stefan Hajnoczi <stefanha@redhat.com> wrote:
> >
> > The following changes since commit 27c94566379069fb8930bb1433dcffbf7df3203d:
> >
> >   Merge remote-tracking branch 'remotes/edgar/tags/edgar/xilinx-next-2020-04-30.for-upstream' into staging (2020-04-30 16:47:23 +0100)
> >
> > are available in the Git repository at:
> >
> >   https://github.com/stefanha/qemu.git tags/block-pull-request
> >
> > for you to fetch changes up to cc1adc4488059ac16d4d2772a7aa7cd1323deeca:
> >
> >   lockable: Replace locks with lock guard macros (2020-05-01 09:19:25 +0100)
> >
> > ----------------------------------------------------------------
> > Pull request
> >
> > Fix the QEMU_LOCK_GUARD() macros, use them more widely, and allow the fuzzer
> > target to be selected from argv[0].
> >
> > ----------------------------------------------------------------
> 
> Hi; this pullreq seems to include a stray change to the slirp
> submodule in the "fuzz: select fuzz target using executable name"
> commit. Could you fix that and resend, please?
> 
> (You might like to include a molly-guard in your pullreq
> creation scripts; on my end I catch this sort of thing
> when applying with a test like
> if git diff master..staging | grep -q 'Subproject commit'; then
>     # complain and exit unless I used an explicit command
>     # line option to say I intended to include a submodule update
> fi
> 
> though I haven't yet put the same test in the script I use
> to send pullreqs, for some reason. I guess my workflow now
> means I don't tend to accidentally commit submodule changes.)

Sorry for the spurious change.  Will send a v2!

Stefan

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

[PULL 0/4] Block patches

[Hanna Reitz]

The following changes since commit 8cb41fda78c7ebde0dd248c6afe1d336efb0de50:

  Merge remote-tracking branch 'remotes/philmd/tags/machine-20211101' into staging (2021-11-02 05:53:45 -0400)

are available in the Git repository at:

  https://github.com/XanClic/qemu.git tags/pull-block-2021-11-02

for you to fetch changes up to 7da9623cc078229caf07c290e16401ccdb9408d2:

  block/vpc: Add a sanity check that fixed-size images have the right type (2021-11-02 12:47:51 +0100)

----------------------------------------------------------------
Emanuele Giuseppe Esposito (1):
  pylint: fix errors and warnings generated by tests/qemu-iotests/297

Eric Blake (1):
  qemu-img: Consistent docs for convert -F

Thomas Huth (1):
  block/vpc: Add a sanity check that fixed-size images have the right
    type

Thomas Weißschuh (1):
  vmdk: allow specification of tools version

 docs/tools/qemu-img.rst                 |  2 +-
 qapi/block-core.json                    |  3 +++
 block/vmdk.c                            | 24 ++++++++++++++++++++----
 block/vpc.c                             |  3 ++-
 qemu-img-cmds.hx                        |  2 +-
 tests/qemu-iotests/129                  | 18 +++++++++---------
 tests/qemu-iotests/310                  | 16 ++++++++--------
 tests/qemu-iotests/check                | 11 ++++++-----
 tests/qemu-iotests/iotests.py           |  7 ++++---
 tests/qemu-iotests/tests/image-fleecing |  4 ++--
 10 files changed, 56 insertions(+), 34 deletions(-)

-- 
2.31.1

Re: [PULL 0/4] Block patches

[Richard Henderson]

On 11/2/21 10:22 AM, Hanna Reitz wrote:
> The following changes since commit 8cb41fda78c7ebde0dd248c6afe1d336efb0de50:
> 
>    Merge remote-tracking branch 'remotes/philmd/tags/machine-20211101' into staging (2021-11-02 05:53:45 -0400)
> 
> are available in the Git repository at:
> 
>    https://github.com/XanClic/qemu.git tags/pull-block-2021-11-02
> 
> for you to fetch changes up to 7da9623cc078229caf07c290e16401ccdb9408d2:
> 
>    block/vpc: Add a sanity check that fixed-size images have the right type (2021-11-02 12:47:51 +0100)
> 
> ----------------------------------------------------------------
> Emanuele Giuseppe Esposito (1):
>    pylint: fix errors and warnings generated by tests/qemu-iotests/297
> 
> Eric Blake (1):
>    qemu-img: Consistent docs for convert -F
> 
> Thomas Huth (1):
>    block/vpc: Add a sanity check that fixed-size images have the right
>      type
> 
> Thomas Weißschuh (1):
>    vmdk: allow specification of tools version
> 
>   docs/tools/qemu-img.rst                 |  2 +-
>   qapi/block-core.json                    |  3 +++
>   block/vmdk.c                            | 24 ++++++++++++++++++++----
>   block/vpc.c                             |  3 ++-
>   qemu-img-cmds.hx                        |  2 +-
>   tests/qemu-iotests/129                  | 18 +++++++++---------
>   tests/qemu-iotests/310                  | 16 ++++++++--------
>   tests/qemu-iotests/check                | 11 ++++++-----
>   tests/qemu-iotests/iotests.py           |  7 ++++---
>   tests/qemu-iotests/tests/image-fleecing |  4 ++--
>   10 files changed, 56 insertions(+), 34 deletions(-)

Applied, thanks.

r~