Branch: refs/heads/master
Home: https://github.com/qemu/qemu
Commit: a9c8ea95470c27a8a02062b67f9fa6940e828ab6
https://github.com/qemu/qemu/commit/a9c8ea95470c27a8a02062b67f9fa6940e828ab6
Author: Ari Sundholm <a...@tuxera.com>
Date: 2024-01-26 (Fri, 26 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 <a...@tuxera.com>
Cc: qemu-sta...@nongnu.org
Message-ID: <20240109184646.1128475-1-meg...@gmx.com>
Reviewed-by: Kevin Wolf <kw...@redhat.com>
Signed-off-by: Kevin Wolf <kw...@redhat.com>
Commit: 014b99a8e41c8cd1e895137654b44dec5430122c
https://github.com/qemu/qemu/commit/014b99a8e41c8cd1e895137654b44dec5430122c
Author: Kevin Wolf <kw...@redhat.com>
Date: 2024-01-26 (Fri, 26 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 <ali...@redhat.com>
Signed-off-by: Kevin Wolf <kw...@redhat.com>
Message-ID: <20240109181717.42493-1-kw...@redhat.com>
Reviewed-by: Stefan Hajnoczi <stefa...@redhat.com>
Signed-off-by: Kevin Wolf <kw...@redhat.com>
Commit: 4b028cbe7540b302d48f7d9e59a8cb860209d9fa
https://github.com/qemu/qemu/commit/4b028cbe7540b302d48f7d9e59a8cb860209d9fa
Author: Peter Krempa <pkre...@redhat.com>
Date: 2024-01-26 (Fri, 26 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 <pkre...@redhat.com>
Reviewed-by: Vladimir Sementsov-Ogievskiy <vsement...@yandex-team.ru>
Message-ID:
<2cb46e37093ce793ea1604abc8bbb90f4c8e434b.1701796348.git.pkre...@redhat.com>
Reviewed-by: Kevin Wolf <kw...@redhat.com>
Signed-off-by: Kevin Wolf <kw...@redhat.com>
Commit: 72098a3aba7a7fccd7d1287c2ff88c1dac9b807d
https://github.com/qemu/qemu/commit/72098a3aba7a7fccd7d1287c2ff88c1dac9b807d
Author: Peter Krempa <pkre...@redhat.com>
Date: 2024-01-26 (Fri, 26 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 <pkre...@redhat.com>
Reviewed-by: Vladimir Sementsov-Ogievskiy <vsement...@yandex-team.ru>
Message-ID:
<bbee9a0a59748a8893289bf8249f568f0d587e62.1701796348.git.pkre...@redhat.com>
Reviewed-by: Kevin Wolf <kw...@redhat.com>
Signed-off-by: Kevin Wolf <kw...@redhat.com>
Commit: da62b507a20510d819bcfbe8f5e573409b954006
https://github.com/qemu/qemu/commit/da62b507a20510d819bcfbe8f5e573409b954006
Author: Stefan Hajnoczi <stefa...@redhat.com>
Date: 2024-01-26 (Fri, 26 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 <stefa...@redhat.com>
Message-ID: <20240118144823.1497953-2-stefa...@redhat.com>
Reviewed-by: Kevin Wolf <kw...@redhat.com>
Signed-off-by: Kevin Wolf <kw...@redhat.com>
Commit: 9ee2dd4c22a3639c5462b3fc20df60c005c3de64
https://github.com/qemu/qemu/commit/9ee2dd4c22a3639c5462b3fc20df60c005c3de64
Author: Stefan Hajnoczi <stefa...@redhat.com>
Date: 2024-01-26 (Fri, 26 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 <hre...@redhat.com>
Signed-off-by: Stefan Hajnoczi <stefa...@redhat.com>
Message-ID: <20240118144823.1497953-3-stefa...@redhat.com>
Reviewed-by: Kevin Wolf <kw...@redhat.com>
Signed-off-by: Kevin Wolf <kw...@redhat.com>
Commit: effd60c878176bcaf97fa7ce2b12d04bb8ead6f7
https://github.com/qemu/qemu/commit/effd60c878176bcaf97fa7ce2b12d04bb8ead6f7
Author: Stefan Hajnoczi <stefa...@redhat.com>
Date: 2024-01-26 (Fri, 26 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-sta...@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 <stefa...@redhat.com>
Message-ID: <20240118144823.1497953-4-stefa...@redhat.com>
Reviewed-by: Kevin Wolf <kw...@redhat.com>
Tested-by: Fiona Ebner <f.eb...@proxmox.com>
Signed-off-by: Kevin Wolf <kw...@redhat.com>
Commit: 3bcc17f06526754fd675dcf601414442044fa0b6
https://github.com/qemu/qemu/commit/3bcc17f06526754fd675dcf601414442044fa0b6
Author: Stefan Hajnoczi <stefa...@redhat.com>
Date: 2024-01-26 (Fri, 26 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 <stefa...@redhat.com>
Message-ID: <20240119135748.270944-2-stefa...@redhat.com>
Reviewed-by: Kevin Wolf <kw...@redhat.com>
Signed-off-by: Kevin Wolf <kw...@redhat.com>
Commit: 57bc2658935778d1ae0edbcd4402763da8c7bae2
https://github.com/qemu/qemu/commit/57bc2658935778d1ae0edbcd4402763da8c7bae2
Author: Stefan Hajnoczi <stefa...@redhat.com>
Date: 2024-01-26 (Fri, 26 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 <stefa...@redhat.com>
Message-ID: <20240119135748.270944-3-stefa...@redhat.com>
Reviewed-by: Kevin Wolf <kw...@redhat.com>
Signed-off-by: Kevin Wolf <kw...@redhat.com>
Commit: 3cdaf3dd4a4ca94ebabe7eab23b432f1a6c547cc
https://github.com/qemu/qemu/commit/3cdaf3dd4a4ca94ebabe7eab23b432f1a6c547cc
Author: Stefan Hajnoczi <stefa...@redhat.com>
Date: 2024-01-26 (Fri, 26 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 <stefa...@redhat.com>
Message-ID: <20240119135748.270944-4-stefa...@redhat.com>
Reviewed-by: Kevin Wolf <kw...@redhat.com>
Signed-off-by: Kevin Wolf <kw...@redhat.com>
Commit: 71ee0cdd14cc01a8b51aa4e9577dd0a1bb2f8e19
https://github.com/qemu/qemu/commit/71ee0cdd14cc01a8b51aa4e9577dd0a1bb2f8e19
Author: Stefan Hajnoczi <stefa...@redhat.com>
Date: 2024-01-26 (Fri, 26 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 <stefa...@redhat.com>
Message-ID: <20240119135748.270944-5-stefa...@redhat.com>
Reviewed-by: Kevin Wolf <kw...@redhat.com>
Signed-off-by: Kevin Wolf <kw...@redhat.com>
Commit: ea0736d7f84ead109a6b701427991828f97724c3
https://github.com/qemu/qemu/commit/ea0736d7f84ead109a6b701427991828f97724c3
Author: Stefan Hajnoczi <stefa...@redhat.com>
Date: 2024-01-26 (Fri, 26 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 <kw...@redhat.com>
Signed-off-by: Stefan Hajnoczi <stefa...@redhat.com>
Message-ID: <20240119135748.270944-6-stefa...@redhat.com>
Reviewed-by: Kevin Wolf <kw...@redhat.com>
Signed-off-by: Kevin Wolf <kw...@redhat.com>
Commit: d3f6f294aeadd5f88caf0155e4360808c95b3146
https://github.com/qemu/qemu/commit/d3f6f294aeadd5f88caf0155e4360808c95b3146
Author: Stefan Hajnoczi <stefa...@redhat.com>
Date: 2024-01-26 (Fri, 26 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 <kw...@redhat.com>
Signed-off-by: Stefan Hajnoczi <stefa...@redhat.com>
Message-ID: <20240119135748.270944-7-stefa...@redhat.com>
Reviewed-by: Kevin Wolf <kw...@redhat.com>
Signed-off-by: Kevin Wolf <kw...@redhat.com>
Commit: a26d018c94ec367172d8376f00be4a31f74bf0d2
https://github.com/qemu/qemu/commit/a26d018c94ec367172d8376f00be4a31f74bf0d2
Author: Ari Sundholm <a...@tuxera.com>
Date: 2024-01-26 (Fri, 26 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 <a...@tuxera.com>
Message-ID: <20240119162913.2620245-1-...@tuxera.com>
Reviewed-by: Kevin Wolf <kw...@redhat.com>
Signed-off-by: Kevin Wolf <kw...@redhat.com>
Commit: 85d5d2b255b63a03fbbfebf85eaeb5eb525d5f9c
https://github.com/qemu/qemu/commit/85d5d2b255b63a03fbbfebf85eaeb5eb525d5f9c
Author: Andrey Drobyshev <andrey.drobys...@virtuozzo.com>
Date: 2024-01-26 (Fri, 26 Jan 2024)
Changed paths:
M tests/qemu-iotests/264
Log Message:
-----------
iotests/264: Use iotests.sock_dir for socket creation
If socket path is too long (longer than 108 bytes), socket can't be
opened. This might lead to failure when test dir path is long enough.
Make sure socket is created in iotests.sock_dir to avoid such a case.
This commit basically aligns iotests/264 with the rest of iotests.
Signed-off-by: Andrey Drobyshev <andrey.drobys...@virtuozzo.com>
Message-ID: <20240125135237.189493-1-andrey.drobys...@virtuozzo.com>
Reviewed-by: Kevin Wolf <kw...@redhat.com>
Reviewed-by: Eric Blake <ebl...@redhat.com>
Signed-off-by: Kevin Wolf <kw...@redhat.com>
Commit: 63b18312d14ac984acaf13c7c55d9baa2d61496e
https://github.com/qemu/qemu/commit/63b18312d14ac984acaf13c7c55d9baa2d61496e
Author: Kevin Wolf <kw...@redhat.com>
Date: 2024-01-26 (Fri, 26 Jan 2024)
Changed paths:
M tests/unit/meson.build
Log Message:
-----------
tests/unit: Bump test-replication timeout to 60 seconds
We're seeing timeouts for this test on CI runs (specifically for
ubuntu-20.04-s390x-all). It doesn't fail consistently, but even the
successful runs take about 27 or 28 seconds, which is not very far from
the 30 seconds timeout.
Bump the timeout a bit to make failure less likely even on this CI host.
Signed-off-by: Kevin Wolf <kw...@redhat.com>
Message-ID: <20240125165803.48373-1-kw...@redhat.com>
Reviewed-by: Thomas Huth <th...@redhat.com>
Signed-off-by: Kevin Wolf <kw...@redhat.com>
Commit: c9c0b37ff4c11b712b21efabe8e5381d223d0295
https://github.com/qemu/qemu/commit/c9c0b37ff4c11b712b21efabe8e5381d223d0295
Author: Kevin Wolf <kw...@redhat.com>
Date: 2024-01-26 (Fri, 26 Jan 2024)
Changed paths:
M tests/qemu-iotests/tests/iothreads-stream
Log Message:
-----------
iotests/iothreads-stream: Use the right TimeoutError
Since Python 3.11 asyncio.TimeoutError is an alias for TimeoutError, but
in older versions it's not. We really have to catch asyncio.TimeoutError
here, otherwise a slow test run will fail (as has happened multiple
times on CI recently).
Signed-off-by: Kevin Wolf <kw...@redhat.com>
Message-ID: <20240125152150.42389-1-kw...@redhat.com>
Signed-off-by: Kevin Wolf <kw...@redhat.com>
Commit: acf2b9fce9f402b070a65bea584582df0378da9e
https://github.com/qemu/qemu/commit/acf2b9fce9f402b070a65bea584582df0378da9e
Author: Andrey Drobyshev <andrey.drobys...@virtuozzo.com>
Date: 2024-01-26 (Fri, 26 Jan 2024)
Changed paths:
M tests/qemu-iotests/277
Log Message:
-----------
iotests/277: Use iotests.sock_dir for socket creation
If socket path is too long (longer than 108 bytes), socket can't be
opened. This might lead to failure when test dir path is long enough.
Make sure socket is created in iotests.sock_dir to avoid such a case.
This commit basically aligns iotests/277 with the rest of iotests.
Signed-off-by: Andrey Drobyshev <andrey.drobys...@virtuozzo.com>
Message-ID: <20240124162257.168325-1-andrey.drobys...@virtuozzo.com>
Reviewed-by: Eric Blake <ebl...@redhat.com>
Reviewed-by: Kevin Wolf <kw...@redhat.com>
Signed-off-by: Kevin Wolf <kw...@redhat.com>
Commit: b9c4a2018aa9c89233b8fc68ce26faf8e4ce1c78
https://github.com/qemu/qemu/commit/b9c4a2018aa9c89233b8fc68ce26faf8e4ce1c78
Author: Peter Maydell <peter.mayd...@linaro.org>
Date: 2024-01-26 (Fri, 26 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/264
M tests/qemu-iotests/273.out
M tests/qemu-iotests/277
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/iothreads-stream
M tests/qemu-iotests/tests/qsd-jobs.out
M tests/unit/meson.build
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
- Some iotest fixes
# -----BEGIN PGP SIGNATURE-----
#
# iQJFBAABCAAvFiEE3D3rFZqa+V09dFb+fwmycsiPL9YFAmWzpOwRHGt3b2xmQHJl
# ZGhhdC5jb20ACgkQfwmycsiPL9ZNzg//W1+C7HxLft4Jc4O1BcOoOLlGCg4Esupt
# z0/XLZ9+xVQUtjQ82pFzf9XaWQs8CuNT3FBUKi+ngdwZ0JBThIv0aGiMZBcAeQjD
# qshPFgDM1lGL4ICIaT73/qfUzQgO3oruZj9F+ShBBzoasNWVoRzqqVDR3pinLwTp
# D4TU+3A6LkdhlYGT60SYfRq/UKNmCA1s2wysdjqXxS6KOEURNF2VBnz0Nu76qrVb
# 3P/a55GPiJIn+VVsdQ0J4vyyzn23m7I7WZOJ7Sjm1EfSJ6SvcDbhWsZTUonaV2rU
# qZ3WI/jggqxXRV8F2AaA4suS/Cc8RkX2KfcN8fB6wDC2eI5USSatjh6xfw5xH9Ll
# NRKUO4vFFR3Lf8wN9apg0Bwxqi0GOm9kvBJT5QqjQ16R1dvqBLqbZqcx6ZXqWFXe
# /Iy243Tz19mWTFVUj0EgCKQpNz9F4SyXxV83HtSR1lJ5mhthnLxkvUOe7jsFPE4d
# 1Z3uBNWnx2mKFkhlwocMTKayYqxPuKQ+YjqrRoplLW1GZoBeoalKRGf8/RHa6kQx
# gh4cguihlb71AH1AO1QuYpiZt9G4RJR2RZlIoCPJY5TaKJedcxMVn8H+8/F0PnQd
# gPysZf7hTU1xCUV6TClDd+f2fuvqZYwXdwHJ9iiohNkbFq4HFQUp4nk4/eEPGSe/
# uv8oE813E30=
# =KQJl
# -----END PGP SIGNATURE-----
# gpg: Signature made Fri 26 Jan 2024 12:26:20 GMT
# gpg: using RSA key DC3DEB159A9AF95D3D7456FE7F09B272C88F2FD6
# gpg: issuer "kw...@redhat.com"
# gpg: Good signature from "Kevin Wolf <kw...@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:
iotests/277: Use iotests.sock_dir for socket creation
iotests/iothreads-stream: Use the right TimeoutError
tests/unit: Bump test-replication timeout to 60 seconds
iotests/264: Use iotests.sock_dir for socket creation
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.mayd...@linaro.org>
Compare: https://github.com/qemu/qemu/compare/e029fe22caad...b9c4a2018aa9
