The following changes since commit cc329c491768b2d91eb0b0984f3baa0bf805776d:

  Merge tag 'block-pull-request' of https://gitlab.com/stefanha/qemu into staging (2026-06-08 09:30:30 -0400)

are available in the Git repository at:

  https://repo.or.cz/qemu/kevin.git tags/for-upstream

for you to fetch changes up to 296b66d05bac7eb2b86600febdbd2bd8d410f026:

  qed: Don't try to flush during incoming migration (2026-06-08 17:00:47 +0200)

----------------------------------------------------------------
Block layer patches

- qcow2: Fix data loss on zero write with detect-zeroes=unmap
- qemu-img bitmap: add sub-command --remove-all
- export/fuse: set FUSE_DIRECT_IO_ALLOW_MMAP flag to fix regression
- virtio-blk: add missing VIRTIO_BLK_T_SCSI_CMD size check (CVE-2026-48914)
- qed: Don't try to flush during incoming migration
- iotests/136: Test stats-intervals with -blockdev/-device

----------------------------------------------------------------
Denis V. Lunev (1):
      qemu-img: add sub-command --remove-all to 'qemu-img bitmap'

Fabiano Rosas (1):
      qed: Don't try to flush during incoming migration

Fiona Ebner (3):
      block/export/fuse: use struct fuse_init_in
      block/export/fuse: set FUSE_DIRECT_IO_ALLOW_MMAP flag to fix regression
      iotests: test shared mmap for fuse export

Kevin Wolf (1):
      iotests/136: Test stats-intervals with -blockdev/-device

Stefan Hajnoczi (1):
      virtio-blk: add missing VIRTIO_BLK_T_SCSI_CMD size check (CVE-2026-48914)

Thomas Lamprecht (1):
      qcow2: Fix data loss on zero write with detect-zeroes=unmap

 docs/tools/qemu-img.rst                       |  10 ++-
 block/qcow2.h                                 |   4 +
 block/export/fuse.c                           |  69 +++++++++++++----
 block/qcow2-cluster.c                         |  10 +--
 block/qcow2.c                                 |   8 +-
 block/qed.c                                   |  16 ++--
 hw/block/virtio-blk.c                         |   8 +-
 qemu-img.c                                    |  55 ++++++++++++--
 tests/qemu-iotests/046                        |  23 ++++++
 tests/qemu-iotests/046.out                    |  10 +++
 tests/qemu-iotests/136                        |  87 +++++++++++++++++++---
 tests/qemu-iotests/136.out                    |   4 +-
 tests/qemu-iotests/tests/fuse-mmap-shared     | 103 ++++++++++++++++++++++++++
 tests/qemu-iotests/tests/fuse-mmap-shared.out |   5 ++
 tests/qemu-iotests/tests/qemu-img-bitmaps     |  24 ++++++
 tests/qemu-iotests/tests/qemu-img-bitmaps.out |  46 ++++++++++++
 16 files changed, 430 insertions(+), 52 deletions(-)
 create mode 100755 tests/qemu-iotests/tests/fuse-mmap-shared
 create mode 100644 tests/qemu-iotests/tests/fuse-mmap-shared.out

On Mon, Jun 8, 2026 at 12:52 PM Kevin Wolf <kwolf@redhat.com> wrote:
>
> The following changes since commit cc329c491768b2d91eb0b0984f3baa0bf805776d:
>
>   Merge tag 'block-pull-request' of https://gitlab.com/stefanha/qemu into staging (2026-06-08 09:30:30 -0400)
>
> are available in the Git repository at:
>
>   https://repo.or.cz/qemu/kevin.git tags/for-upstream
>
> for you to fetch changes up to 296b66d05bac7eb2b86600febdbd2bd8d410f026:
>
>   qed: Don't try to flush during incoming migration (2026-06-08 17:00:47 +0200)
>
> ----------------------------------------------------------------
> Block layer patches
>
> - qcow2: Fix data loss on zero write with detect-zeroes=unmap
> - qemu-img bitmap: add sub-command --remove-all
> - export/fuse: set FUSE_DIRECT_IO_ALLOW_MMAP flag to fix regression

Hi Fiona and Kevin,
Please take a look at the CI failure below. If the root cause is in
this pull request, please send a new revision with fixed patches or
without the patches that cause the failure. Thanks!

>>> UBSAN_OPTIONS=halt_on_error=1:abort_on_error=1:print_summary=1:print_stacktrace=1 LD_LIBRARY_PATH=/builds/qemu-project/qemu/build/subprojects/libvfio-user/lib MALLOC_PERTURB_=83 MESON_TEST_ITERATION=1 ASAN_OPTIONS=halt_on_error=1:abort_on_error=1:print_summary=1 MSAN_OPTIONS=halt_on_error=1:abort_on_error=1:print_summary=1:print_stacktrace=1 PYTHON=/builds/qemu-project/qemu/build/pyvenv/bin/python3 RUST_BACKTRACE=1 /builds/qemu-project/qemu/build/pyvenv/bin/python3 /builds/qemu-project/qemu/build/../tests/qemu-iotests/check -tap -luks fuse-mmap-shared --source-dir /builds/qemu-project/qemu/tests/qemu-iotests --build-dir /builds/qemu-project/qemu/build/tests/qemu-iotests
――――――――――――――――――――――――――――――――――――― ✀ ―――――――――――――――――――――――――――――――――――――
stderr:
--- /builds/qemu-project/qemu/tests/qemu-iotests/tests/fuse-mmap-shared.out
+++ /builds/qemu-project/qemu/build/scratch/luks-file-fuse-mmap-shared/fuse-mmap-shared.out.bad
@@ -1,5 +1,22 @@
-.
+E
+======================================================================
+ERROR: test_mmap_shared (__main__.TestMmapShared)
+----------------------------------------------------------------------
+Traceback (most recent call last):
+ File "/builds/qemu-project/qemu/tests/qemu-iotests/tests/fuse-mmap-shared",
line 55, in setUp
+ qemu_io(image, '-c', f'write -P 23 0 {image_size}')
+ File "/builds/qemu-project/qemu/tests/qemu-iotests/iotests.py", line
364, in qemu_io
+ return qemu_tool(*qemu_io_wrap_args(args),
+ File "/builds/qemu-project/qemu/tests/qemu-iotests/iotests.py", line
241, in qemu_tool
+ raise VerboseProcessError(
+qemu.utils.VerboseProcessError: Command
'('/builds/qemu-project/qemu/build/qemu-io', '--cache', 'writeback',
'--aio', 'threads',
'/builds/qemu-project/qemu/build/scratch/luks-file-fuse-mmap-shared/image.luks',
'-c', 'write -P 23 0 1048576')' returned non-zero exit status 1.
+ ┏━ output ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
+ ┃ qemu-io: can't open device /builds/qemu-project/qemu/build/scratch/
+ ┃ luks-file-fuse-mmap-shared/image.luks: Parameter 'key-secret' is
+ ┃ required for cipher
+ ┗━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
+
----------------------------------------------------------------------
Ran 1 tests
-OK
+FAILED (errors=1)

https://gitlab.com/qemu-project/qemu/-/jobs/14772570524#L257

Stefan

> - virtio-blk: add missing VIRTIO_BLK_T_SCSI_CMD size check (CVE-2026-48914)
> - qed: Don't try to flush during incoming migration
> - iotests/136: Test stats-intervals with -blockdev/-device
>
> ----------------------------------------------------------------
> Denis V. Lunev (1):
>       qemu-img: add sub-command --remove-all to 'qemu-img bitmap'
>
> Fabiano Rosas (1):
>       qed: Don't try to flush during incoming migration
>
> Fiona Ebner (3):
>       block/export/fuse: use struct fuse_init_in
>       block/export/fuse: set FUSE_DIRECT_IO_ALLOW_MMAP flag to fix regression
>       iotests: test shared mmap for fuse export
>
> Kevin Wolf (1):
>       iotests/136: Test stats-intervals with -blockdev/-device
>
> Stefan Hajnoczi (1):
>       virtio-blk: add missing VIRTIO_BLK_T_SCSI_CMD size check (CVE-2026-48914)
>
> Thomas Lamprecht (1):
>       qcow2: Fix data loss on zero write with detect-zeroes=unmap
>
>  docs/tools/qemu-img.rst                       |  10 ++-
>  block/qcow2.h                                 |   4 +
>  block/export/fuse.c                           |  69 +++++++++++++----
>  block/qcow2-cluster.c                         |  10 +--
>  block/qcow2.c                                 |   8 +-
>  block/qed.c                                   |  16 ++--
>  hw/block/virtio-blk.c                         |   8 +-
>  qemu-img.c                                    |  55 ++++++++++++--
>  tests/qemu-iotests/046                        |  23 ++++++
>  tests/qemu-iotests/046.out                    |  10 +++
>  tests/qemu-iotests/136                        |  87 +++++++++++++++++++---
>  tests/qemu-iotests/136.out                    |   4 +-
>  tests/qemu-iotests/tests/fuse-mmap-shared     | 103 ++++++++++++++++++++++++++
>  tests/qemu-iotests/tests/fuse-mmap-shared.out |   5 ++
>  tests/qemu-iotests/tests/qemu-img-bitmaps     |  24 ++++++
>  tests/qemu-iotests/tests/qemu-img-bitmaps.out |  46 ++++++++++++
>  16 files changed, 430 insertions(+), 52 deletions(-)
>  create mode 100755 tests/qemu-iotests/tests/fuse-mmap-shared
>  create mode 100644 tests/qemu-iotests/tests/fuse-mmap-shared.out
>
>

Am 09.06.2026 um 19:44 hat Stefan Hajnoczi geschrieben:
> On Mon, Jun 8, 2026 at 12:52 PM Kevin Wolf <kwolf@redhat.com> wrote:
> >
> > The following changes since commit cc329c491768b2d91eb0b0984f3baa0bf805776d:
> >
> >   Merge tag 'block-pull-request' of https://gitlab.com/stefanha/qemu into staging (2026-06-08 09:30:30 -0400)
> >
> > are available in the Git repository at:
> >
> >   https://repo.or.cz/qemu/kevin.git tags/for-upstream
> >
> > for you to fetch changes up to 296b66d05bac7eb2b86600febdbd2bd8d410f026:
> >
> >   qed: Don't try to flush during incoming migration (2026-06-08 17:00:47 +0200)
> >
> > ----------------------------------------------------------------
> > Block layer patches
> >
> > - qcow2: Fix data loss on zero write with detect-zeroes=unmap
> > - qemu-img bitmap: add sub-command --remove-all
> > - export/fuse: set FUSE_DIRECT_IO_ALLOW_MMAP flag to fix regression
> 
> Hi Fiona and Kevin,
> Please take a look at the CI failure below. If the root cause is in
> this pull request, please send a new revision with fixed patches or
> without the patches that cause the failure. Thanks!

Yes, it's a new test case introduced in this series that doesn't work
with the luks driver. I just declared luks unsupported for the test for
now and pushed a v2 (will send the new cover letter in a moment, too).

Kevin

Am 10.06.26 um 12:14 PM schrieb Kevin Wolf:
> Am 09.06.2026 um 19:44 hat Stefan Hajnoczi geschrieben:
>> On Mon, Jun 8, 2026 at 12:52 PM Kevin Wolf <kwolf@redhat.com> wrote:
>>>
>>> The following changes since commit cc329c491768b2d91eb0b0984f3baa0bf805776d:
>>>
>>>   Merge tag 'block-pull-request' of https://gitlab.com/stefanha/qemu into staging (2026-06-08 09:30:30 -0400)
>>>
>>> are available in the Git repository at:
>>>
>>>   https://repo.or.cz/qemu/kevin.git tags/for-upstream
>>>
>>> for you to fetch changes up to 296b66d05bac7eb2b86600febdbd2bd8d410f026:
>>>
>>>   qed: Don't try to flush during incoming migration (2026-06-08 17:00:47 +0200)
>>>
>>> ----------------------------------------------------------------
>>> Block layer patches
>>>
>>> - qcow2: Fix data loss on zero write with detect-zeroes=unmap
>>> - qemu-img bitmap: add sub-command --remove-all
>>> - export/fuse: set FUSE_DIRECT_IO_ALLOW_MMAP flag to fix regression
>>
>> Hi Fiona and Kevin,
>> Please take a look at the CI failure below. If the root cause is in
>> this pull request, please send a new revision with fixed patches or
>> without the patches that cause the failure. Thanks!
> 
> Yes, it's a new test case introduced in this series that doesn't work
> with the luks driver. I just declared luks unsupported for the test for
> now and pushed a v2 (will send the new cover letter in a moment, too).

Sorry and thanks! I'll need to remember to check with luks in the future.

Best Regards,
Fiona

On Wed, Jun 10, 2026 at 12:18:48PM +0200, Fiona Ebner wrote:
> Am 10.06.26 um 12:14 PM schrieb Kevin Wolf:
> > Am 09.06.2026 um 19:44 hat Stefan Hajnoczi geschrieben:
> >> On Mon, Jun 8, 2026 at 12:52 PM Kevin Wolf <kwolf@redhat.com> wrote:
> >>>
> >>> The following changes since commit cc329c491768b2d91eb0b0984f3baa0bf805776d:
> >>>
> >>>   Merge tag 'block-pull-request' of https://gitlab.com/stefanha/qemu into staging (2026-06-08 09:30:30 -0400)
> >>>
> >>> are available in the Git repository at:
> >>>
> >>>   https://repo.or.cz/qemu/kevin.git tags/for-upstream
> >>>
> >>> for you to fetch changes up to 296b66d05bac7eb2b86600febdbd2bd8d410f026:
> >>>
> >>>   qed: Don't try to flush during incoming migration (2026-06-08 17:00:47 +0200)
> >>>
> >>> ----------------------------------------------------------------
> >>> Block layer patches
> >>>
> >>> - qcow2: Fix data loss on zero write with detect-zeroes=unmap
> >>> - qemu-img bitmap: add sub-command --remove-all
> >>> - export/fuse: set FUSE_DIRECT_IO_ALLOW_MMAP flag to fix regression
> >>
> >> Hi Fiona and Kevin,
> >> Please take a look at the CI failure below. If the root cause is in
> >> this pull request, please send a new revision with fixed patches or
> >> without the patches that cause the failure. Thanks!
> > 
> > Yes, it's a new test case introduced in this series that doesn't work
> > with the luks driver. I just declared luks unsupported for the test for
> > now and pushed a v2 (will send the new cover letter in a moment, too).
> 
> Sorry and thanks! I'll need to remember to check with luks in the future.

You just got unlucky with the new expanded CI testing introduced when
my pull request was merged a few days ago.  Previously gitlab CI only
tested qcow2 and raw, and so compat with other drivers was "best effort"
after the fact.

Now the gitlab CI runs I/O tests across 10 drivers, so it needs to
work before merge, which is something contributors didn't need to
think about before now.

If you push a branch to your gitlab fork and trigger CI, you'll see
the results in the "block" job in the pipeline results. 

With regards,
Daniel
-- 
|: https://berrange.com       ~~        https://hachyderm.io/@berrange :|
|: https://libvirt.org          ~~          https://entangle-photo.org :|
|: https://pixelfed.art/berrange   ~~    https://fstop138.berrange.com :|

Am 10.06.2026 um 13:17 hat Daniel P. Berrangé geschrieben:
> You just got unlucky with the new expanded CI testing introduced when
> my pull request was merged a few days ago.  Previously gitlab CI only
> tested qcow2 and raw, and so compat with other drivers was "best effort"
> after the fact.
> 
> Now the gitlab CI runs I/O tests across 10 drivers, so it needs to
> work before merge, which is something contributors didn't need to
> think about before now.
> 
> If you push a branch to your gitlab fork and trigger CI, you'll see
> the results in the "block" job in the pipeline results. 

Technically true, but who has the CI minutes to actually do this? I
don't think we've figured out a solution yet how people (or at least
maintainers) can use QEMU's minutes from the open source program prior
to sending a patch series or pull request. Or have we?

Kevin

On Wed, Jun 10, 2026 at 01:39:16PM +0200, Kevin Wolf wrote:
> Am 10.06.2026 um 13:17 hat Daniel P. Berrangé geschrieben:
> > You just got unlucky with the new expanded CI testing introduced when
> > my pull request was merged a few days ago.  Previously gitlab CI only
> > tested qcow2 and raw, and so compat with other drivers was "best effort"
> > after the fact.
> > 
> > Now the gitlab CI runs I/O tests across 10 drivers, so it needs to
> > work before merge, which is something contributors didn't need to
> > think about before now.
> > 
> > If you push a branch to your gitlab fork and trigger CI, you'll see
> > the results in the "block" job in the pipeline results. 
> 
> Technically true, but who has the CI minutes to actually do this?

Pretty much everyone IMHO.

> I don't think we've figured out a solution yet how people (or at least
> maintainers) can use QEMU's minutes from the open source program prior
> to sending a patch series or pull request. Or have we?

GitLab user accounts get 400 minutes of CI credits.

Forks of QEMU though are only charged at a cost fact or 0.008 since
we are a member of the OSS program

  https://docs.gitlab.com/ci/pipelines/compute_minutes/#cost-factors-of-hosted-runners-for-gitlabcom

IOW, you're charged 1 minute per 125 minutes of job time.

A single QEMU pipline run in my fork today cost 4.5 credits. That's
enough for 87 pipeline runs per month, if I was not contributing to
anything outside QEMU on gitlab.com.

If you run a pipeline to sanity check before sending a patch series
I don't think most people will ever run out of credits.

If you run multiple pipelines a day during development then you might
be pushing your luck. Better to use the local "make docker-...."
targets for day-to-day testing during dev, and just use gitlab
pipelines before submission.

With regards,
Daniel
-- 
|: https://berrange.com       ~~        https://hachyderm.io/@berrange :|
|: https://libvirt.org          ~~          https://entangle-photo.org :|
|: https://pixelfed.art/berrange   ~~    https://fstop138.berrange.com :|

Am 10.06.2026 um 13:48 hat Daniel P. Berrangé geschrieben:
> On Wed, Jun 10, 2026 at 01:39:16PM +0200, Kevin Wolf wrote:
> > Am 10.06.2026 um 13:17 hat Daniel P. Berrangé geschrieben:
> > > You just got unlucky with the new expanded CI testing introduced when
> > > my pull request was merged a few days ago.  Previously gitlab CI only
> > > tested qcow2 and raw, and so compat with other drivers was "best effort"
> > > after the fact.
> > > 
> > > Now the gitlab CI runs I/O tests across 10 drivers, so it needs to
> > > work before merge, which is something contributors didn't need to
> > > think about before now.
> > > 
> > > If you push a branch to your gitlab fork and trigger CI, you'll see
> > > the results in the "block" job in the pipeline results. 
> > 
> > Technically true, but who has the CI minutes to actually do this?
> 
> Pretty much everyone IMHO.
> 
> > I don't think we've figured out a solution yet how people (or at least
> > maintainers) can use QEMU's minutes from the open source program prior
> > to sending a patch series or pull request. Or have we?
> 
> GitLab user accounts get 400 minutes of CI credits.
> 
> Forks of QEMU though are only charged at a cost fact or 0.008 since
> we are a member of the OSS program
> 
>   https://docs.gitlab.com/ci/pipelines/compute_minutes/#cost-factors-of-hosted-runners-for-gitlabcom
> 
> IOW, you're charged 1 minute per 125 minutes of job time.
> 
> A single QEMU pipline run in my fork today cost 4.5 credits. That's
> enough for 87 pipeline runs per month, if I was not contributing to
> anything outside QEMU on gitlab.com.
> 
> If you run a pipeline to sanity check before sending a patch series
> I don't think most people will ever run out of credits.
> 
> If you run multiple pipelines a day during development then you might
> be pushing your luck. Better to use the local "make docker-...."
> targets for day-to-day testing during dev, and just use gitlab
> pipelines before submission.

Did this change at some point? Because I'm quite sure I stopped doing
full CI runs only after running out of minutes with very moderate use.
Ever since then, I've only manually started individual jobs when I had
reason to suspect there could be a problem with them.

Kevin

On Wed, Jun 10, 2026 at 02:21:33PM +0200, Kevin Wolf wrote:
> Am 10.06.2026 um 13:48 hat Daniel P. Berrangé geschrieben:
> > On Wed, Jun 10, 2026 at 01:39:16PM +0200, Kevin Wolf wrote:
> > > Am 10.06.2026 um 13:17 hat Daniel P. Berrangé geschrieben:
> > > > You just got unlucky with the new expanded CI testing introduced when
> > > > my pull request was merged a few days ago.  Previously gitlab CI only
> > > > tested qcow2 and raw, and so compat with other drivers was "best effort"
> > > > after the fact.
> > > > 
> > > > Now the gitlab CI runs I/O tests across 10 drivers, so it needs to
> > > > work before merge, which is something contributors didn't need to
> > > > think about before now.
> > > > 
> > > > If you push a branch to your gitlab fork and trigger CI, you'll see
> > > > the results in the "block" job in the pipeline results. 
> > > 
> > > Technically true, but who has the CI minutes to actually do this?
> > 
> > Pretty much everyone IMHO.
> > 
> > > I don't think we've figured out a solution yet how people (or at least
> > > maintainers) can use QEMU's minutes from the open source program prior
> > > to sending a patch series or pull request. Or have we?
> > 
> > GitLab user accounts get 400 minutes of CI credits.
> > 
> > Forks of QEMU though are only charged at a cost fact or 0.008 since
> > we are a member of the OSS program
> > 
> >   https://docs.gitlab.com/ci/pipelines/compute_minutes/#cost-factors-of-hosted-runners-for-gitlabcom
> > 
> > IOW, you're charged 1 minute per 125 minutes of job time.
> > 
> > A single QEMU pipline run in my fork today cost 4.5 credits. That's
> > enough for 87 pipeline runs per month, if I was not contributing to
> > anything outside QEMU on gitlab.com.
> > 
> > If you run a pipeline to sanity check before sending a patch series
> > I don't think most people will ever run out of credits.
> > 
> > If you run multiple pipelines a day during development then you might
> > be pushing your luck. Better to use the local "make docker-...."
> > targets for day-to-day testing during dev, and just use gitlab
> > pipelines before submission.
> 
> Did this change at some point? Because I'm quite sure I stopped doing
> full CI runs only after running out of minutes with very moderate use.
> Ever since then, I've only manually started individual jobs when I had
> reason to suspect there could be a problem with them.

Yes, there was a time window when QEMU was *not* part of the OSS
program and so forks would get charged at the full 1:1 rate. At the
same time gitlab was transitioning personal accounts from two different
CI limits, so those with newer accounts would run out much faster
due to a lower limit than other people with older accounts like myself.
Everyone now has the same 400 minute limit, with the 0.008 cost factor
inherited.

The only caveat is that your git repo *MUST* be a direct fork of
qemu-project/qemu.git in order to inherit the cost factor.

So, yes, there were problems in the past, but it should be much
better for most people today.


And we do have the "QEMU_CI=1" push option to trigger individual
jobs manually vs  "QEMU_CI=2" run unleashes the whole pipeline,
so users can conserve CI credits if debugging a specific job
over & over again.

With regards,
Daniel
-- 
|: https://berrange.com       ~~        https://hachyderm.io/@berrange :|
|: https://libvirt.org          ~~          https://entangle-photo.org :|
|: https://pixelfed.art/berrange   ~~    https://fstop138.berrange.com :|