Series comparison

-[PULL 0/4] Block patches
+[PULL for-6.1 0/3] Block patches
-The following changes since commit 560009f2c8b57b7cdd31a5693ea86ab369382f49:
+The following changes since commit 3521ade3510eb5cefb2e27a101667f25dad89935:
-  Merge remote-tracking branch 'remotes/kevin/tags/for-upstream' into staging (2019-10-07 15:40:53 +0100)
+  Merge remote-tracking branch 'remotes/thuth-gitlab/tags/pull-request-2021-07-29' into staging (2021-07-29 13:17:20 +0100)
 are available in the Git repository at:
-  https://github.com/stefanha/qemu.git tags/block-pull-request
+  https://gitlab.com/stefanha/qemu.git tags/block-pull-request
-for you to fetch changes up to 4d804b5305ffb4d5fa414c38d4f1bdfb987c8d0b:
+for you to fetch changes up to cc8eecd7f105a1dff5876adeb238a14696061a4a:
-  iotests/262: Switch source/dest VM launch order (2019-10-08 14:28:25 +0100)
+  MAINTAINERS: Added myself as a reviewer for the NVMe Block Driver (2021-07-29 17:17:34 +0100)
 ----------------------------------------------------------------
 Pull request
-This pull request also contains the two commits from the previous pull request
+The main fix here is for io_uring. Spurious -EAGAIN errors can happen and the
-that was dropped due to a mingw compilation error.  The compilation should now
+request needs to be resubmitted.
-be fixed.
 The MAINTAINERS changes carry no risk and we might as well include them in QEMU
 .1.
 ----------------------------------------------------------------
-Max Reitz (2):
+Fabian Ebner (1):
-  block: Skip COR for inactive nodes
+  block/io_uring: resubmit when result is -EAGAIN
   iotests/262: Switch source/dest VM launch order
-Sergio Lopez (1):
+Philippe Mathieu-Daudé (1):
-  virtio-blk: schedule virtio_notify_config to run on main context
+  MAINTAINERS: Added myself as a reviewer for the NVMe Block Driver
-Vladimir Sementsov-Ogievskiy (1):
+Stefano Garzarella (1):
-  util/ioc.c: try to reassure Coverity about qemu_iovec_init_extended
+  MAINTAINERS: add Stefano Garzarella as io_uring reviewer
- block/io.c                 | 41 +++++++++++++++++++++++++-------------
+ MAINTAINERS      |  2 ++
- hw/block/virtio-blk.c      | 16 ++++++++++++++-
+ block/io_uring.c | 16 +++++++++++++++-
- util/iov.c                 |  5 +++--
+files changed, 17 insertions(+), 1 deletion(-)
  tests/qemu-iotests/262     | 12 +++++------
  tests/qemu-iotests/262.out |  6 +++---
 files changed, 54 insertions(+), 26 deletions(-)
 --
-.21.0
+.31.1

-[PULL 1/4] util/ioc.c: try to reassure Coverity about qemu_iovec_init_extended
+Deleted patch
-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 +++--
-file changed, 3 insertions(+), 2 deletions(-)
-diff --git a/util/iov.c b/util/iov.c
-index XXXXXXX..XXXXXXX 100644
---- a/util/iov.c
-+++ b/util/iov.c
-@@ -XXX,XX +XXX,XX @@ 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,
-@@ -XXX,XX +XXX,XX @@ 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;
---
-.21.0

-[PULL 4/4] iotests/262: Switch source/dest VM launch order
+[PULL for-6.1 1/3] MAINTAINERS: add Stefano Garzarella as io_uring reviewer
-From: Max Reitz <mreitz@redhat.com>
+From: Stefano Garzarella <sgarzare@redhat.com>
-Launching the destination VM before the source VM gives us a regression
+I've been working with io_uring for a while so I'd like to help
-test for HEAD^:
+with reviews.
-The guest device causes a read from the disk image through
+Signed-off-by: Stefano Garzarella <sgarzare@redhat.com>
-guess_disk_lchs().  This will not work if the first sector (containing
+Message-Id: <20210728131515.131045-1-sgarzare@redhat.com>
 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 ++++++------
+ MAINTAINERS | 1 +
- tests/qemu-iotests/262.out |  6 +++---
+file changed, 1 insertion(+)
 files changed, 9 insertions(+), 9 deletions(-)
-diff --git a/tests/qemu-iotests/262 b/tests/qemu-iotests/262
+diff --git a/MAINTAINERS b/MAINTAINERS
 index XXXXXXX..XXXXXXX 100755
 --- a/tests/qemu-iotests/262
 +++ b/tests/qemu-iotests/262
@@ -XXX,XX +XXX,XX @@ 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))
@@ -XXX,XX +XXX,XX @@ 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 XXXXXXX..XXXXXXX 100644
---- a/tests/qemu-iotests/262.out
+--- a/MAINTAINERS
-+++ b/tests/qemu-iotests/262.out
++++ b/MAINTAINERS
-@@ -XXX,XX +XXX,XX @@
+@@ -XXX,XX +XXX,XX @@ Linux io_uring
--Launching source VM...
+ M: Aarushi Mehta <mehta.aaru20@gmail.com>
--Enabling migration QMP events on A...
+ M: Julia Suvorova <jusual@redhat.com>
--{"return": {}}
+ M: Stefan Hajnoczi <stefanha@redhat.com>
- Launching destination VM...
++R: Stefano Garzarella <sgarzare@redhat.com>
- Enabling migration QMP events on B...
+ L: qemu-block@nongnu.org
- {"return": {}}
+ S: Maintained
-+Launching source VM...
+ F: block/io_uring.c
 +Enabling migration QMP events on A...
 +{"return": {}}
  Starting migration to B...
  {"return": {}}
  {"data": {"status": "setup"}, "event": "MIGRATION", "timestamp": {"microseconds": "USECS", "seconds": "SECS"}}
 --
-.21.0
+.31.1

-[PULL 2/4] virtio-blk: schedule virtio_notify_config to run on main context
+[PULL for-6.1 2/3] block/io_uring: resubmit when result is -EAGAIN
-From: Sergio Lopez <slp@redhat.com>
+From: Fabian Ebner <f.ebner@proxmox.com>
-virtio_notify_config() needs to acquire the global mutex, which isn't
+Linux SCSI can throw spurious -EAGAIN in some corner cases in its
-allowed from an iothread, and may lead to a deadlock like this:
+completion path, which will end up being the result in the completed
 io_uring request.
- - main thead
+Resubmitting such requests should allow block jobs to complete, even
-  * Has acquired: qemu_global_mutex.
+if such spurious errors are encountered.
   * Is trying the acquire: iothread AioContext lock via
     AIO_WAIT_WHILE (after aio_poll).
- - iothread
+Co-authored-by: Stefan Hajnoczi <stefanha@gmail.com>
-  * Has acquired: AioContext lock.
+Reviewed-by: Stefano Garzarella <sgarzare@redhat.com>
-  * Is trying to acquire: qemu_global_mutex (via
+Signed-off-by: Fabian Ebner <f.ebner@proxmox.com>
-    virtio_notify_config->prepare_mmio_access).
+Message-id: 20210729091029.65369-1-f.ebner@proxmox.com
 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 +++++++++++++++-
+ block/io_uring.c | 16 +++++++++++++++-
 file changed, 15 insertions(+), 1 deletion(-)
-diff --git a/hw/block/virtio-blk.c b/hw/block/virtio-blk.c
+diff --git a/block/io_uring.c b/block/io_uring.c
 index XXXXXXX..XXXXXXX 100644
---- a/hw/block/virtio-blk.c
+--- a/block/io_uring.c
-+++ b/hw/block/virtio-blk.c
++++ b/block/io_uring.c
-@@ -XXX,XX +XXX,XX @@
+@@ -XXX,XX +XXX,XX @@ static void luring_process_completions(LuringState *s)
- #include "qemu/iov.h"
+         total_bytes = ret + luringcb->total_read;
- #include "qemu/module.h"
- #include "qemu/error-report.h"
+         if (ret < 0) {
-+#include "qemu/main-loop.h"
+-            if (ret == -EINTR) {
- #include "trace.h"
++            /*
- #include "hw/block/block.h"
++             * Only writev/readv/fsync requests on regular files or host block
- #include "hw/qdev-properties.h"
++             * devices are submitted. Therefore -EAGAIN is not expected but it's
-@@ -XXX,XX +XXX,XX @@ static int virtio_blk_load_device(VirtIODevice *vdev, QEMUFile *f,
++             * known to happen sometimes with Linux SCSI. Submit again and hope
-     return 0;
++             * the request completes successfully.
- }
++             *
++             * For more information, see:
-+static void virtio_resize_cb(void *opaque)
++             * https://lore.kernel.org/io-uring/20210727165811.284510-3-axboe@kernel.dk/T/#u
-+{
++             *
-+    VirtIODevice *vdev = opaque;
++             * If the code is changed to submit other types of requests in the
-+
++             * future, then this workaround may need to be extended to deal with
-+    assert(qemu_get_current_aio_context() == qemu_get_aio_context());
++             * genuine -EAGAIN results that should not be resubmitted
-+    virtio_notify_config(vdev);
++             * immediately.
-+}
++             */
-+
++            if (ret == -EINTR || ret == -EAGAIN) {
- static void virtio_blk_resize(void *opaque)
+                 luring_resubmit(s, luringcb);
- {
+                 continue;
-     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 = {
 --
-.21.0
+.31.1

-[PULL 3/4] block: Skip COR for inactive nodes
+[PULL for-6.1 3/3] MAINTAINERS: Added myself as a reviewer for the NVMe Block Driver
-From: Max Reitz <mreitz@redhat.com>
+From: Philippe Mathieu-Daudé <philmd@redhat.com>
-We must not write data to inactive nodes, and a COR is certainly
+I'm interested in following the activity around the NVMe bdrv.
 something we can simply not do without upsetting anyone.  So skip COR
 operations on inactive nodes.
-Signed-off-by: Max Reitz <mreitz@redhat.com>
+Signed-off-by: Philippe Mathieu-Daudé <philmd@redhat.com>
-Reviewed-by: Eric Blake <eblake@redhat.com>
+Message-id: 20210728183340.2018313-1-philmd@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 +++++++++++++++++++++++++++--------------
+ MAINTAINERS | 1 +
-file changed, 27 insertions(+), 14 deletions(-)
+file changed, 1 insertion(+)
-diff --git a/block/io.c b/block/io.c
+diff --git a/MAINTAINERS b/MAINTAINERS
 index XXXXXXX..XXXXXXX 100644
---- a/block/io.c
+--- a/MAINTAINERS
-+++ b/block/io.c
++++ b/MAINTAINERS
-@@ -XXX,XX +XXX,XX @@ static int coroutine_fn bdrv_co_do_copy_on_readv(BdrvChild *child,
+@@ -XXX,XX +XXX,XX @@ F: block/null.c
-     int max_transfer = MIN_NON_ZERO(bs->bl.max_transfer,
+ NVMe Block Driver
-                                     BDRV_REQUEST_MAX_BYTES);
+ M: Stefan Hajnoczi <stefanha@redhat.com>
-     unsigned int progress = 0;
+ R: Fam Zheng <fam@euphon.net>
-+    bool skip_write;
++R: Philippe Mathieu-Daudé <philmd@redhat.com>
+ L: qemu-block@nongnu.org
-     if (!drv) {
+ S: Supported
-         return -ENOMEDIUM;
+ F: block/nvme*
      }
 +    /*
 +     * 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
@@ -XXX,XX +XXX,XX @@ 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;
 --
-.21.0
+.31.1

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

-- 
2.21.0

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 XXXXXXX..XXXXXXX 100644
--- a/util/iov.c
+++ b/util/iov.c
@@ -XXX,XX +XXX,XX @@ 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,
@@ -XXX,XX +XXX,XX @@ 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

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 XXXXXXX..XXXXXXX 100644
--- a/hw/block/virtio-blk.c
+++ b/hw/block/virtio-blk.c
@@ -XXX,XX +XXX,XX @@
 #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"
@@ -XXX,XX +XXX,XX @@ 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

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 XXXXXXX..XXXXXXX 100644
--- a/block/io.c
+++ b/block/io.c
@@ -XXX,XX +XXX,XX @@ 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
@@ -XXX,XX +XXX,XX @@ 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

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 XXXXXXX..XXXXXXX 100755
--- a/tests/qemu-iotests/262
+++ b/tests/qemu-iotests/262
@@ -XXX,XX +XXX,XX @@ 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))
@@ -XXX,XX +XXX,XX @@ 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 XXXXXXX..XXXXXXX 100644
--- a/tests/qemu-iotests/262.out
+++ b/tests/qemu-iotests/262.out
@@ -XXX,XX +XXX,XX @@
-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

The following changes since commit 3521ade3510eb5cefb2e27a101667f25dad89935:

Merge remote-tracking branch 'remotes/thuth-gitlab/tags/pull-request-2021-07-29' into staging (2021-07-29 13:17:20 +0100)

are available in the Git repository at:

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

for you to fetch changes up to cc8eecd7f105a1dff5876adeb238a14696061a4a:

MAINTAINERS: Added myself as a reviewer for the NVMe Block Driver (2021-07-29 17:17:34 +0100)

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

The main fix here is for io_uring. Spurious -EAGAIN errors can happen and the
request needs to be resubmitted.

The MAINTAINERS changes carry no risk and we might as well include them in QEMU
6.1.

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

Fabian Ebner (1):
  block/io_uring: resubmit when result is -EAGAIN

Philippe Mathieu-Daudé (1):
  MAINTAINERS: Added myself as a reviewer for the NVMe Block Driver

Stefano Garzarella (1):
  MAINTAINERS: add Stefano Garzarella as io_uring reviewer

MAINTAINERS      |  2 ++
 block/io_uring.c | 16 +++++++++++++++-
 2 files changed, 17 insertions(+), 1 deletion(-)

-- 
2.31.1

From: Fabian Ebner <f.ebner@proxmox.com>

Linux SCSI can throw spurious -EAGAIN in some corner cases in its
completion path, which will end up being the result in the completed
io_uring request.

Resubmitting such requests should allow block jobs to complete, even
if such spurious errors are encountered.

Co-authored-by: Stefan Hajnoczi <stefanha@gmail.com>
Reviewed-by: Stefano Garzarella <sgarzare@redhat.com>
Signed-off-by: Fabian Ebner <f.ebner@proxmox.com>
Message-id: 20210729091029.65369-1-f.ebner@proxmox.com
Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
---
 block/io_uring.c | 16 +++++++++++++++-
 1 file changed, 15 insertions(+), 1 deletion(-)

diff --git a/block/io_uring.c b/block/io_uring.c
index XXXXXXX..XXXXXXX 100644
--- a/block/io_uring.c
+++ b/block/io_uring.c
@@ -XXX,XX +XXX,XX @@ static void luring_process_completions(LuringState *s)
         total_bytes = ret + luringcb->total_read;
 
         if (ret < 0) {
-            if (ret == -EINTR) {
+            /*
+             * Only writev/readv/fsync requests on regular files or host block
+             * devices are submitted. Therefore -EAGAIN is not expected but it's
+             * known to happen sometimes with Linux SCSI. Submit again and hope
+             * the request completes successfully.
+             *
+             * For more information, see:
+             * https://lore.kernel.org/io-uring/20210727165811.284510-3-axboe@kernel.dk/T/#u
+             *
+             * If the code is changed to submit other types of requests in the
+             * future, then this workaround may need to be extended to deal with
+             * genuine -EAGAIN results that should not be resubmitted
+             * immediately.
+             */
+            if (ret == -EINTR || ret == -EAGAIN) {
                 luring_resubmit(s, luringcb);
                 continue;
             }
-- 
2.31.1