[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Qemu-commits] [qemu/qemu] b080f4: block/blklogwrites: Fix a bug when lo
|
From: |
Peter Maydell |
|
Subject: |
[Qemu-commits] [qemu/qemu] b080f4: block/blklogwrites: Fix a bug when logging "write ... |
|
Date: |
Tue, 23 Jan 2024 08:43:25 -0800 |
Branch: refs/heads/staging
Home: https://github.com/qemu/qemu
Commit: b080f425c8ed44a69875eb69f37f6456405d3296
https://github.com/qemu/qemu/commit/b080f425c8ed44a69875eb69f37f6456405d3296
Author: Ari Sundholm <ari@tuxera.com>
Date: 2024-01-19 (Fri, 19 Jan 2024)
Changed paths:
M block/blklogwrites.c
Log Message:
-----------
block/blklogwrites: Fix a bug when logging "write zeroes" operations.
There is a bug in the blklogwrites driver pertaining to logging "write
zeroes" operations, causing log corruption. This can be easily observed
by setting detect-zeroes to something other than "off" for the driver.
The issue is caused by a concurrency bug pertaining to the fact that
"write zeroes" operations have to be logged in two parts: first the log
entry metadata, then the zeroed-out region. While the log entry
metadata is being written by bdrv_co_pwritev(), another operation may
begin in the meanwhile and modify the state of the blklogwrites driver.
This is as intended by the coroutine-driven I/O model in QEMU, of
course.
Unfortunately, this specific scenario is mishandled. A short example:
1. Initially, in the current operation (#1), the current log sector
number in the driver state is only incremented by the number of sectors
taken by the log entry metadata, after which the log entry metadata is
written. The current operation yields.
2. Another operation (#2) may start while the log entry metadata is
being written. It uses the current log position as the start offset for
its log entry. This is in the sector right after the operation #1 log
entry metadata, which is bad!
3. After bdrv_co_pwritev() returns (#1), the current log sector
number is reread from the driver state in order to find out the start
offset for bdrv_co_pwrite_zeroes(). This is an obvious blunder, as the
offset will be the sector right after the (misplaced) operation #2 log
entry, which means that the zeroed-out region begins at the wrong
offset.
4. As a result of the above, the log is corrupt.
Fix this by only reading the driver metadata once, computing the
offsets and sizes in one go (including the optional zeroed-out region)
and setting the log sector number to the appropriate value for the next
operation in line.
Signed-off-by: Ari Sundholm <ari@tuxera.com>
Cc: qemu-stable@nongnu.org
Message-ID: <20240109184646.1128475-1-megari@gmx.com>
Reviewed-by: Kevin Wolf <kwolf@redhat.com>
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
Commit: 14f2a372ee1c3779de61fb2d08cb231c478de882
https://github.com/qemu/qemu/commit/14f2a372ee1c3779de61fb2d08cb231c478de882
Author: Kevin Wolf <kwolf@redhat.com>
Date: 2024-01-19 (Fri, 19 Jan 2024)
Changed paths:
M qapi/string-output-visitor.c
Log Message:
-----------
string-output-visitor: Fix (pseudo) struct handling
Commit ff32bb53 tried to get minimal struct support into the string
output visitor by just making it return "<omitted>". Unfortunately, it
forgot that the caller will still make more visitor calls for the
content of the struct.
If the struct is contained in a list, such as IOThreadVirtQueueMapping,
in the better case its fields show up as separate list entries. In the
worse case, it contains another list, and the string output visitor
doesn't support nested lists and asserts that this doesn't happen. So as
soon as the optional "vqs" field in IOThreadVirtQueueMapping is
specified, we get a crash.
This can be reproduced with the following command line:
echo "info qtree" | ./qemu-system-x86_64 \
-object iothread,id=t0 \
-blockdev null-co,node-name=disk \
-device '{"driver": "virtio-blk-pci", "drive": "disk",
"iothread-vq-mapping": [{"iothread": "t0", "vqs": [0]}]}' \
-monitor stdio
Fix the problem by counting the nesting level of structs and ignoring
any visitor calls for values (apart from start/end_struct) while we're
not on the top level.
Lists nested directly within lists remain unimplemented, as we don't
currently have a use case for them.
Fixes: ff32bb53476539d352653f4ed56372dced73a388
Resolves: https://gitlab.com/qemu-project/qemu/-/issues/2069
Reported-by: Aihua Liang <aliang@redhat.com>
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
Message-ID: <20240109181717.42493-1-kwolf@redhat.com>
Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com>
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
Commit: 5ce5461bc4da6f14f0b75828abbb254a8e23d3dc
https://github.com/qemu/qemu/commit/5ce5461bc4da6f14f0b75828abbb254a8e23d3dc
Author: Peter Krempa <pkrempa@redhat.com>
Date: 2024-01-19 (Fri, 19 Jan 2024)
Changed paths:
M block.c
M block/commit.c
M blockdev.c
M include/block/block-global-state.h
M include/block/block_int-common.h
M include/block/block_int-global-state.h
M qapi/block-core.json
M tests/unit/test-bdrv-drain.c
Log Message:
-----------
commit: Allow users to request only format driver names in backing file format
Introduce a new flag 'backing-mask-protocol' for the block-commit QMP
command which instructs the internals to use 'raw' instead of the
protocol driver in case when a image is used without a dummy 'raw'
wrapper.
The flag is designed such that it can be always asserted by management
tools even when there isn't any update to backing files.
The flag will be used by libvirt so that the backing images still
reference the proper format even when libvirt will stop using the dummy
raw driver (raw driver with no other config). Libvirt needs this so that
the images stay compatible with older libvirt versions which didn't
expect that a protocol driver name can appear in the backing file format
field.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Vladimir Sementsov-Ogievskiy <vsementsov@yandex-team.ru>
Message-ID:
<2cb46e37093ce793ea1604abc8bbb90f4c8e434b.1701796348.git.pkrempa@redhat.com>
Reviewed-by: Kevin Wolf <kwolf@redhat.com>
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
Commit: bc8c0b95dc9615df9c5ebd9e39186b2e825e6ab7
https://github.com/qemu/qemu/commit/bc8c0b95dc9615df9c5ebd9e39186b2e825e6ab7
Author: Peter Krempa <pkrempa@redhat.com>
Date: 2024-01-19 (Fri, 19 Jan 2024)
Changed paths:
M block/monitor/block-hmp-cmds.c
M block/stream.c
M blockdev.c
M include/block/block_int-global-state.h
M qapi/block-core.json
Log Message:
-----------
stream: Allow users to request only format driver names in backing file format
Introduce a new flag 'backing-mask-protocol' for the block-stream QMP
command which instructs the internals to use 'raw' instead of the
protocol driver in case when a image is used without a dummy 'raw'
wrapper.
The flag is designed such that it can be always asserted by management
tools even when there isn't any update to backing files.
The flag will be used by libvirt so that the backing images still
reference the proper format even when libvirt will stop using the dummy
raw driver (raw driver with no other config). Libvirt needs this so that
the images stay compatible with older libvirt versions which didn't
expect that a protocol driver name can appear in the backing file format
field.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Vladimir Sementsov-Ogievskiy <vsementsov@yandex-team.ru>
Message-ID:
<bbee9a0a59748a8893289bf8249f568f0d587e62.1701796348.git.pkrempa@redhat.com>
Reviewed-by: Kevin Wolf <kwolf@redhat.com>
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
Commit: 5dea5d6b0e16c4e02f1e8b23f5880c8c05714b84
https://github.com/qemu/qemu/commit/5dea5d6b0e16c4e02f1e8b23f5880c8c05714b84
Author: Stefan Hajnoczi <stefanha@redhat.com>
Date: 2024-01-19 (Fri, 19 Jan 2024)
Changed paths:
M tests/qemu-iotests/iotests.py
Log Message:
-----------
iotests: add filter_qmp_generated_node_ids()
Add a filter function for QMP responses that contain QEMU's
automatically generated node ids. The ids change between runs and must
be masked in the reference output.
The next commit will use this new function.
Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
Message-ID: <20240118144823.1497953-2-stefanha@redhat.com>
Reviewed-by: Kevin Wolf <kwolf@redhat.com>
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
Commit: 8b57e45dac5b4fce9a1efb80197815469406c3fa
https://github.com/qemu/qemu/commit/8b57e45dac5b4fce9a1efb80197815469406c3fa
Author: Stefan Hajnoczi <stefanha@redhat.com>
Date: 2024-01-19 (Fri, 19 Jan 2024)
Changed paths:
M tests/qemu-iotests/141
M tests/qemu-iotests/141.out
Log Message:
-----------
iotests: port 141 to Python for reliable QMP testing
The common.qemu bash functions allow tests to interact with the QMP
monitor of a QEMU process. I spent two days trying to update 141 when
the order of the test output changed, but found it would still fail
occassionally because printf() and QMP events race with synchronous QMP
communication.
I gave up and ported 141 to the existing Python API for QMP tests. The
Python API is less affected by the order in which QEMU prints output
because it does not print all QMP traffic by default.
The next commit changes the order in which QMP messages are received.
Make 141 reliable first.
Cc: Hanna Czenczek <hreitz@redhat.com>
Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
Message-ID: <20240118144823.1497953-3-stefanha@redhat.com>
Reviewed-by: Kevin Wolf <kwolf@redhat.com>
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
Commit: 6ab9622eaac6c3bcd31b8d64fb5712835d58a846
https://github.com/qemu/qemu/commit/6ab9622eaac6c3bcd31b8d64fb5712835d58a846
Author: Stefan Hajnoczi <stefanha@redhat.com>
Date: 2024-01-19 (Fri, 19 Jan 2024)
Changed paths:
M monitor/qmp.c
M qapi/qmp-dispatch.c
M tests/qemu-iotests/060.out
M tests/qemu-iotests/071.out
M tests/qemu-iotests/081.out
M tests/qemu-iotests/087.out
M tests/qemu-iotests/108.out
M tests/qemu-iotests/109
M tests/qemu-iotests/109.out
M tests/qemu-iotests/117.out
M tests/qemu-iotests/120.out
M tests/qemu-iotests/127.out
M tests/qemu-iotests/140.out
M tests/qemu-iotests/143.out
M tests/qemu-iotests/156.out
M tests/qemu-iotests/176.out
M tests/qemu-iotests/182.out
M tests/qemu-iotests/183.out
M tests/qemu-iotests/184.out
M tests/qemu-iotests/185
M tests/qemu-iotests/185.out
M tests/qemu-iotests/191.out
M tests/qemu-iotests/195.out
M tests/qemu-iotests/223.out
M tests/qemu-iotests/227.out
M tests/qemu-iotests/247.out
M tests/qemu-iotests/273.out
M tests/qemu-iotests/308
M tests/qemu-iotests/308.out
M tests/qemu-iotests/tests/file-io-error
M tests/qemu-iotests/tests/iothreads-resize.out
M tests/qemu-iotests/tests/qsd-jobs.out
Log Message:
-----------
monitor: only run coroutine commands in qemu_aio_context
monitor_qmp_dispatcher_co() runs in the iohandler AioContext that is not
polled during nested event loops. The coroutine currently reschedules
itself in the main loop's qemu_aio_context AioContext, which is polled
during nested event loops. One known problem is that QMP device-add
calls drain_call_rcu(), which temporarily drops the BQL, leading to all
sorts of havoc like other vCPU threads re-entering device emulation code
while another vCPU thread is waiting in device emulation code with
aio_poll().
Paolo Bonzini suggested running non-coroutine QMP handlers in the
iohandler AioContext. This avoids trouble with nested event loops. His
original idea was to move coroutine rescheduling to
monitor_qmp_dispatch(), but I resorted to moving it to qmp_dispatch()
because we don't know if the QMP handler needs to run in coroutine
context in monitor_qmp_dispatch(). monitor_qmp_dispatch() would have
been nicer since it's associated with the monitor implementation and not
as general as qmp_dispatch(), which is also used by qemu-ga.
A number of qemu-iotests need updated .out files because the order of
QMP events vs QMP responses has changed.
Solves Issue #1933.
Cc: qemu-stable@nongnu.org
Fixes: 7bed89958bfbf40df9ca681cefbdca63abdde39d ("device_core: use
drain_call_rcu in in qmp_device_add")
Buglink: https://bugzilla.redhat.com/show_bug.cgi?id=2215192
Buglink: https://bugzilla.redhat.com/show_bug.cgi?id=2214985
Buglink: https://issues.redhat.com/browse/RHEL-17369
Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
Message-ID: <20240118144823.1497953-4-stefanha@redhat.com>
Reviewed-by: Kevin Wolf <kwolf@redhat.com>
Tested-by: Fiona Ebner <f.ebner@proxmox.com>
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
Commit: 806244af64c88faf10e15df34ccbc427529ca96a
https://github.com/qemu/qemu/commit/806244af64c88faf10e15df34ccbc427529ca96a
Author: Stefan Hajnoczi <stefanha@redhat.com>
Date: 2024-01-19 (Fri, 19 Jan 2024)
Changed paths:
M hw/block/dataplane/meson.build
R hw/block/dataplane/trace-events
R hw/block/dataplane/trace.h
R hw/block/dataplane/virtio-blk.c
R hw/block/dataplane/virtio-blk.h
M hw/block/virtio-blk.c
M include/hw/virtio/virtio-blk.h
M meson.build
Log Message:
-----------
virtio-blk: move dataplane code into virtio-blk.c
The dataplane code used to be significantly different from the
non-dataplane code and therefore had a separate source file.
Over time the difference has gotten smaller because the I/O code paths
were unified. Nowadays the distinction between the VirtIOBlock and
VirtIOBlockDataPlane structs is more of an inconvenience that hinders
code simplification.
Move hw/block/dataplane/virtio-blk.c into hw/block/virtio-blk.c, merging
VirtIOBlockDataPlane's fields into VirtIOBlock.
hw/block/virtio-blk.c used VirtIOBlock->dataplane to check if
virtio_blk_data_plane_create() was successful. This is not necessary
because ->dataplane_started and ->dataplane_disabled can be used
instead. This patch makes those changes in order to drop
VirtIOBlock->dataplane.
Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
Message-ID: <20240119135748.270944-2-stefanha@redhat.com>
Reviewed-by: Kevin Wolf <kwolf@redhat.com>
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
Commit: 33e7ad9df01c3d1567e6a3f3cdac5aa3680474eb
https://github.com/qemu/qemu/commit/33e7ad9df01c3d1567e6a3f3cdac5aa3680474eb
Author: Stefan Hajnoczi <stefanha@redhat.com>
Date: 2024-01-19 (Fri, 19 Jan 2024)
Changed paths:
M hw/block/virtio-blk.c
Log Message:
-----------
virtio-blk: rename dataplane create/destroy functions
virtio_blk_data_plane_create() and virtio_blk_data_plane_destroy() are
actually about s->vq_aio_context[] rather than managing
dataplane-specific state.
As a prerequisite to using s->vq_aio_context[] in all code paths (even
when dataplane is not used), rename these functions to reflect that they
just manage s->vq_aio_context and call them regardless of whether or not
dataplane is in use.
Note that virtio-blk supports running with -device
virtio-blk-pci,ioevent=off where the vCPU thread enters the device
emulation code. In this mode ioeventfd is not used for virtqueue
processing. However, we still want to initialize s->vq_aio_context[] to
qemu_aio_context in that case since I/O completion callbacks will be
invoked in the main loop thread.
Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
Message-ID: <20240119135748.270944-3-stefanha@redhat.com>
Reviewed-by: Kevin Wolf <kwolf@redhat.com>
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
Commit: d6317918c85cfd2ac20bee7a0a32c7d8a362b52f
https://github.com/qemu/qemu/commit/d6317918c85cfd2ac20bee7a0a32c7d8a362b52f
Author: Stefan Hajnoczi <stefanha@redhat.com>
Date: 2024-01-19 (Fri, 19 Jan 2024)
Changed paths:
M hw/block/virtio-blk.c
M include/hw/virtio/virtio-blk.h
Log Message:
-----------
virtio-blk: rename dataplane to ioeventfd
The dataplane code is really about using ioeventfd. It's used both for
IOThreads (what we think of as dataplane) and for the core virtio-pci
code's ioeventfd feature (which is enabled by default and used when no
IOThread has been specified). Rename the code to reflect this.
Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
Message-ID: <20240119135748.270944-4-stefanha@redhat.com>
Reviewed-by: Kevin Wolf <kwolf@redhat.com>
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
Commit: 399ca379c2be256a576c731a52a40b78703c2088
https://github.com/qemu/qemu/commit/399ca379c2be256a576c731a52a40b78703c2088
Author: Stefan Hajnoczi <stefanha@redhat.com>
Date: 2024-01-19 (Fri, 19 Jan 2024)
Changed paths:
M hw/block/virtio-blk.c
Log Message:
-----------
virtio-blk: restart s->rq reqs in vq AioContexts
A virtio-blk device with the iothread-vq-mapping parameter has
per-virtqueue AioContexts. It is not thread-safe to process s->rq
requests in the BlockBackend AioContext since that may be different from
the virtqueue's AioContext to which this request belongs. The code
currently races and could crash.
Adapt virtio_blk_dma_restart_cb() to first split s->rq into per-vq lists
and then schedule a BH each vq's AioContext as necessary. This way
requests are safely processed in their vq's AioContext.
Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
Message-ID: <20240119135748.270944-5-stefanha@redhat.com>
Reviewed-by: Kevin Wolf <kwolf@redhat.com>
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
Commit: a4c0be27f4c48907c98c52bb9f31f8f8fe52598b
https://github.com/qemu/qemu/commit/a4c0be27f4c48907c98c52bb9f31f8f8fe52598b
Author: Stefan Hajnoczi <stefanha@redhat.com>
Date: 2024-01-19 (Fri, 19 Jan 2024)
Changed paths:
M hw/block/virtio-blk.c
Log Message:
-----------
virtio-blk: tolerate failure to set BlockBackend AioContext
We no longer rely on setting the AioContext since the block layer
IO_CODE APIs can be called from any thread. Now it's just a hint to help
block jobs and other operations co-locate themselves in a thread with
the guest I/O requests. Keep going if setting the AioContext fails.
Suggested-by: Kevin Wolf <kwolf@redhat.com>
Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
Message-ID: <20240119135748.270944-6-stefanha@redhat.com>
Reviewed-by: Kevin Wolf <kwolf@redhat.com>
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
Commit: 7f48a496cd6bbc5bbcfc7525794afaacc25ddb19
https://github.com/qemu/qemu/commit/7f48a496cd6bbc5bbcfc7525794afaacc25ddb19
Author: Stefan Hajnoczi <stefanha@redhat.com>
Date: 2024-01-19 (Fri, 19 Jan 2024)
Changed paths:
M hw/block/virtio-blk.c
Log Message:
-----------
virtio-blk: always set ioeventfd during startup
When starting ioeventfd it is common practice to set the event notifier
so that the ioeventfd handler is triggered to run immediately. There may
be no requests waiting to be processed, but the idea is that if a
request snuck in then we guarantee that it will be detected.
One scenario where self-triggering the ioeventfd is necessary is when
virtio_blk_handle_output() is called from a vCPU thread before the
VIRTIO Device Status transitions to DRIVER_OK. In that case we need to
self-trigger the ioeventfd so that the kick handled by the vCPU thread
causes the vq AioContext thread to take over handling the request(s).
Fixes: b6948ab01df0 ("virtio-blk: add iothread-vq-mapping parameter")
Reported-by: Kevin Wolf <kwolf@redhat.com>
Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
Message-ID: <20240119135748.270944-7-stefanha@redhat.com>
Reviewed-by: Kevin Wolf <kwolf@redhat.com>
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
Commit: c14962c3ea6f0998d028142ed14affcb9dfccf28
https://github.com/qemu/qemu/commit/c14962c3ea6f0998d028142ed14affcb9dfccf28
Author: Ari Sundholm <ari@tuxera.com>
Date: 2024-01-22 (Mon, 22 Jan 2024)
Changed paths:
M block/blklogwrites.c
Log Message:
-----------
block/blklogwrites: Protect mutable driver state with a mutex.
During the review of a fix for a concurrency issue in blklogwrites,
it was found that the driver needs an additional fix when enabling
multiqueue, which is a new feature introduced in QEMU 9.0, as the
driver state may be read and written by multiple threads at the same
time, which was not the case when the driver was originally written.
Fix the multi-threaded scenario by introducing a mutex to protect the
mutable fields in the driver state, and always having the mutex locked
by the current thread when accessing them. Also use the mutex and a
CoQueue to ensure that the super block is not being written to by
multiple threads concurrently and updates are properly serialized.
Additionally, add the const qualifier to a few BDRVBlkLogWritesState
pointer targets in contexts where the driver state is not written to.
Signed-off-by: Ari Sundholm <ari@tuxera.com>
Message-ID: <20240119162913.2620245-1-ari@tuxera.com>
Reviewed-by: Kevin Wolf <kwolf@redhat.com>
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
Commit: 7c3b52e757537309fa7e9081edd08a70c7bd9f05
https://github.com/qemu/qemu/commit/7c3b52e757537309fa7e9081edd08a70c7bd9f05
Author: Peter Maydell <peter.maydell@linaro.org>
Date: 2024-01-23 (Tue, 23 Jan 2024)
Changed paths:
M block.c
M block/blklogwrites.c
M block/commit.c
M block/monitor/block-hmp-cmds.c
M block/stream.c
M blockdev.c
M hw/block/dataplane/meson.build
R hw/block/dataplane/trace-events
R hw/block/dataplane/trace.h
R hw/block/dataplane/virtio-blk.c
R hw/block/dataplane/virtio-blk.h
M hw/block/virtio-blk.c
M include/block/block-global-state.h
M include/block/block_int-common.h
M include/block/block_int-global-state.h
M include/hw/virtio/virtio-blk.h
M meson.build
M monitor/qmp.c
M qapi/block-core.json
M qapi/qmp-dispatch.c
M qapi/string-output-visitor.c
M tests/qemu-iotests/060.out
M tests/qemu-iotests/071.out
M tests/qemu-iotests/081.out
M tests/qemu-iotests/087.out
M tests/qemu-iotests/108.out
M tests/qemu-iotests/109
M tests/qemu-iotests/109.out
M tests/qemu-iotests/117.out
M tests/qemu-iotests/120.out
M tests/qemu-iotests/127.out
M tests/qemu-iotests/140.out
M tests/qemu-iotests/141
M tests/qemu-iotests/141.out
M tests/qemu-iotests/143.out
M tests/qemu-iotests/156.out
M tests/qemu-iotests/176.out
M tests/qemu-iotests/182.out
M tests/qemu-iotests/183.out
M tests/qemu-iotests/184.out
M tests/qemu-iotests/185
M tests/qemu-iotests/185.out
M tests/qemu-iotests/191.out
M tests/qemu-iotests/195.out
M tests/qemu-iotests/223.out
M tests/qemu-iotests/227.out
M tests/qemu-iotests/247.out
M tests/qemu-iotests/273.out
M tests/qemu-iotests/308
M tests/qemu-iotests/308.out
M tests/qemu-iotests/iotests.py
M tests/qemu-iotests/tests/file-io-error
M tests/qemu-iotests/tests/iothreads-resize.out
M tests/qemu-iotests/tests/qsd-jobs.out
M tests/unit/test-bdrv-drain.c
Log Message:
-----------
Merge tag 'for-upstream' of https://repo.or.cz/qemu/kevin into staging
Block layer patches
- virtio-blk: Multiqueue fixes and cleanups
- blklogwrites: Fixes for write_zeroes and superblock update races
- commit/stream: Allow users to request only format driver names in
backing file format
- monitor: only run coroutine commands in qemu_aio_context
# -----BEGIN PGP SIGNATURE-----
#
# iQJFBAABCAAvFiEE3D3rFZqa+V09dFb+fwmycsiPL9YFAmWuTpoRHGt3b2xmQHJl
# ZGhhdC5jb20ACgkQfwmycsiPL9aRFA//e2lF8VFJzNngch1vx4lOdordnAc6c/qX
# 95UHFgbpiqA8o8i67kTjnn1j6OHPWjuRFCOG0JnqvsoxgC7HqBPewOXSP432YKGd
# Zyu0ZON2mf7YtA5X/THyyWqcTH/w+ferWldvyj1KLbYnTmSveXw8DmFaJhYOAQ4j
# YPkB6W/7IvrqwXgjOve9KgETb5nBwYWQXsLyte4Ng+BWrq4xUE1TvrYt66FRfDUW
# IZbBeYcAOe7ExWR92lxpt/ZQ/tfGor8QfOOFHLm6xegP7Q3ViLu/8CyHNMIg9gCf
# HC8egkIk8v9C3qGf8VpFB/dBzY8hnNUGUNdpmAkk15oVczCDt4XqILnkIBrJ4d+R
# C4xq6oKF1bhcY7IoFbKunxXIZMRZDHEVjHGdW9yWgyYEx/4dt1FrwYPS2jzxhcZz
# 7lSswMMe9vC6jctQGqT98FAUiP2rmmKB2vQ3TDgWL7K5tv/Zt47oU1Hn5Q+2ieVm
# kC2X1cQC8vZQOPn2Rnryk0PK94GW8HsDqN7Wwp64Ld6V8Jxm/eDgTUGI3XoDmgTL
# jVQVAz+WfRcdOasE53RaWMPBKSMvcCG9BfBpjprbzAhJEZ7O3oHv9t7ZWEuaXlXY
# jurwbDVDUWDMF2xqFURGUPgMMwZg5PzXDJk/sS8YIfyBRIdKnQPDjh3UTD0o1sZP
# IjmSWJuEpWE=
# =QDPo
# -----END PGP SIGNATURE-----
# gpg: Signature made Mon 22 Jan 2024 11:16:42 GMT
# gpg: using RSA key DC3DEB159A9AF95D3D7456FE7F09B272C88F2FD6
# gpg: issuer "kwolf@redhat.com"
# gpg: Good signature from "Kevin Wolf <kwolf@redhat.com>" [full]
# Primary key fingerprint: DC3D EB15 9A9A F95D 3D74 56FE 7F09 B272 C88F 2FD6
* tag 'for-upstream' of https://repo.or.cz/qemu/kevin:
block/blklogwrites: Protect mutable driver state with a mutex.
virtio-blk: always set ioeventfd during startup
virtio-blk: tolerate failure to set BlockBackend AioContext
virtio-blk: restart s->rq reqs in vq AioContexts
virtio-blk: rename dataplane to ioeventfd
virtio-blk: rename dataplane create/destroy functions
virtio-blk: move dataplane code into virtio-blk.c
monitor: only run coroutine commands in qemu_aio_context
iotests: port 141 to Python for reliable QMP testing
iotests: add filter_qmp_generated_node_ids()
stream: Allow users to request only format driver names in backing file format
commit: Allow users to request only format driver names in backing file format
string-output-visitor: Fix (pseudo) struct handling
block/blklogwrites: Fix a bug when logging "write zeroes" operations.
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Compare: https://github.com/qemu/qemu/compare/4a4efae44f19...7c3b52e75753