[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Qemu-commits] [qemu/qemu] 1f995a: virtio-blk: enforce iothread-vq-mappi
|
From: |
Peter Maydell |
|
Subject: |
[Qemu-commits] [qemu/qemu] 1f995a: virtio-blk: enforce iothread-vq-mapping validation |
|
Date: |
Fri, 09 Feb 2024 03:22:11 -0800 |
Branch: refs/heads/master
Home: https://github.com/qemu/qemu
Commit: 1f995a4782d140b16d9b24e787053944fb5c4dfb
https://github.com/qemu/qemu/commit/1f995a4782d140b16d9b24e787053944fb5c4dfb
Author: Stefan Hajnoczi <stefanha@redhat.com>
Date: 2024-02-07 (Wed, 07 Feb 2024)
Changed paths:
M hw/block/virtio-blk.c
Log Message:
-----------
virtio-blk: enforce iothread-vq-mapping validation
Hanna Czenczek <hreitz@redhat.com> noticed that the safety of
`vq_aio_context[vq->value] = ctx;` with user-defined vq->value inputs is
not obvious.
The code is structured in validate() + apply() steps so input validation
is there, but it happens way earlier and there is nothing that
guarantees apply() can only be called with validated inputs.
This patch moves the validate() call inside the apply() function so
validation is guaranteed. I also added the bounds checking assertion
that Hanna suggested.
Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
Reviewed-by: Manos Pitsidianakis <manos.pitsidianakis@linaro.org>
Reviewed-by: Hanna Czenczek <hreitz@redhat.com>
Message-ID: <20240206190610.107963-2-stefanha@redhat.com>
Reviewed-by: Kevin Wolf <kwolf@redhat.com>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
Commit: 5fbcbd50fca67ffe35317f2e86f6822aa22e41c6
https://github.com/qemu/qemu/commit/5fbcbd50fca67ffe35317f2e86f6822aa22e41c6
Author: Stefan Hajnoczi <stefanha@redhat.com>
Date: 2024-02-07 (Wed, 07 Feb 2024)
Changed paths:
M hw/block/virtio-blk.c
Log Message:
-----------
virtio-blk: clarify that there is at least 1 virtqueue
It is not possible to instantiate a virtio-blk device with 0 virtqueues.
The following check is located in ->realize():
if (!conf->num_queues) {
error_setg(errp, "num-queues property must be larger than 0");
return;
}
Later on we access s->vq_aio_context[0] under the assumption that there
is as least one virtqueue. Hanna Czenczek <hreitz@redhat.com> noted that
it would help to show that the array index is already valid.
Add an assertion to document that s->vq_aio_context[0] is always
safe...and catch future code changes that break this assumption.
Suggested-by: Hanna Czenczek <hreitz@redhat.com>
Reviewed-by: Manos Pitsidianakis <manos.pitsidianakis@linaro.org>
Reviewed-by: Hanna Czenczek <hreitz@redhat.com>
Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
Message-ID: <20240206190610.107963-3-stefanha@redhat.com>
Reviewed-by: Kevin Wolf <kwolf@redhat.com>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
Commit: f2eea93c6b410efccc18f4b47090b4a4e842afbd
https://github.com/qemu/qemu/commit/f2eea93c6b410efccc18f4b47090b4a4e842afbd
Author: Stefan Hajnoczi <stefanha@redhat.com>
Date: 2024-02-07 (Wed, 07 Feb 2024)
Changed paths:
M hw/block/virtio-blk.c
Log Message:
-----------
virtio-blk: add vq_rq[] bounds check in virtio_blk_dma_restart_cb()
Hanna Czenczek <hreitz@redhat.com> noted that the array index in
virtio_blk_dma_restart_cb() is not bounds-checked:
g_autofree VirtIOBlockReq **vq_rq = g_new0(VirtIOBlockReq *, num_queues);
...
while (rq) {
VirtIOBlockReq *next = rq->next;
uint16_t idx = virtio_get_queue_index(rq->vq);
rq->next = vq_rq[idx];
^^^^^^^^^^
The code is correct because both rq->vq and vq_rq[] depend on
num_queues, but this is indirect and not 100% obvious. Add an assertion.
Suggested-by: Hanna Czenczek <hreitz@redhat.com>
Reviewed-by: Manos Pitsidianakis <manos.pitsidianakis@linaro.org>
Reviewed-by: Hanna Czenczek <hreitz@redhat.com>
Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
Message-ID: <20240206190610.107963-4-stefanha@redhat.com>
Reviewed-by: Kevin Wolf <kwolf@redhat.com>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
Commit: 8802f4f4e3a3e7e0ffc778cab853b14349574a7b
https://github.com/qemu/qemu/commit/8802f4f4e3a3e7e0ffc778cab853b14349574a7b
Author: Stefan Hajnoczi <stefanha@redhat.com>
Date: 2024-02-07 (Wed, 07 Feb 2024)
Changed paths:
M include/hw/virtio/virtio-blk.h
Log Message:
-----------
virtio-blk: declare VirtIOBlock::rq with a type
The VirtIOBlock::rq field has had the type void * since its introduction
in commit 869a5c6df19a ("Stop VM on error in virtio-blk. (Gleb
Natapov)").
Perhaps this was done to avoid the forward declaration of
VirtIOBlockReq.
Hanna Czenczek <hreitz@redhat.com> pointed out the missing type. Specify
the actual type because there is no need to use void * here.
Suggested-by: Hanna Czenczek <hreitz@redhat.com>
Reviewed-by: Manos Pitsidianakis <manos.pitsidianakis@linaro.org>
Reviewed-by: Hanna Czenczek <hreitz@redhat.com>
Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
Message-ID: <20240206190610.107963-5-stefanha@redhat.com>
Reviewed-by: Kevin Wolf <kwolf@redhat.com>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
Commit: 1f25c172f83704e350c0829438d832384084a74d
https://github.com/qemu/qemu/commit/1f25c172f83704e350c0829438d832384084a74d
Author: Stefan Hajnoczi <stefanha@redhat.com>
Date: 2024-02-07 (Wed, 07 Feb 2024)
Changed paths:
M qapi/qmp-dispatch.c
Log Message:
-----------
monitor: use aio_co_reschedule_self()
The aio_co_reschedule_self() API is designed to avoid the race
condition between scheduling the coroutine in another AioContext and
yielding.
The QMP dispatch code uses the open-coded version that appears
susceptible to the race condition at first glance:
aio_co_schedule(qemu_get_aio_context(), qemu_coroutine_self());
qemu_coroutine_yield();
The code is actually safe because the iohandler and qemu_aio_context
AioContext run under the Big QEMU Lock. Nevertheless, set a good example
and use aio_co_reschedule_self() so it's obvious that there is no race.
Suggested-by: Hanna Reitz <hreitz@redhat.com>
Reviewed-by: Manos Pitsidianakis <manos.pitsidianakis@linaro.org>
Reviewed-by: Hanna Czenczek <hreitz@redhat.com>
Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
Message-ID: <20240206190610.107963-6-stefanha@redhat.com>
Reviewed-by: Kevin Wolf <kwolf@redhat.com>
Acked-by: Markus Armbruster <armbru@redhat.com>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
Commit: ad893672027ffe26db498947d70cde6d4f58a111
https://github.com/qemu/qemu/commit/ad893672027ffe26db498947d70cde6d4f58a111
Author: Hanna Czenczek <hreitz@redhat.com>
Date: 2024-02-07 (Wed, 07 Feb 2024)
Changed paths:
M block/block-backend.c
Log Message:
-----------
block-backend: Allow concurrent context changes
Since AioContext locks have been removed, a BlockBackend's AioContext
may really change at any time (only exception is that it is often
confined to a drained section, as noted in this patch). Therefore,
blk_get_aio_context() cannot rely on its root node's context always
matching that of the BlockBackend.
In practice, whether they match does not matter anymore anyway: Requests
can be sent to BDSs from any context, so anyone who requests the BB's
context should have no reason to require the root node to have the same
context. Therefore, we can and should remove the assertion to that
effect.
In addition, because the context can be set and queried from different
threads concurrently, it has to be accessed with atomic operations.
Buglink: https://issues.redhat.com/browse/RHEL-19381
Suggested-by: Kevin Wolf <kwolf@redhat.com>
Signed-off-by: Hanna Czenczek <hreitz@redhat.com>
Message-ID: <20240202144755.671354-2-hreitz@redhat.com>
Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com>
Reviewed-by: Kevin Wolf <kwolf@redhat.com>
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
Commit: 1604c0493193273e4eac547f86fbd2845e7f9af4
https://github.com/qemu/qemu/commit/1604c0493193273e4eac547f86fbd2845e7f9af4
Author: Hanna Czenczek <hreitz@redhat.com>
Date: 2024-02-07 (Wed, 07 Feb 2024)
Changed paths:
M hw/scsi/scsi-bus.c
Log Message:
-----------
scsi: Await request purging
scsi_device_for_each_req_async() currently does not provide any way to
be awaited. One of its callers is scsi_device_purge_requests(), which
therefore currently does not guarantee that all requests are fully
settled when it returns.
We want all requests to be settled, because scsi_device_purge_requests()
is called through the unrealize path, including the one invoked by
virtio_scsi_hotunplug() through qdev_simple_device_unplug_cb(), which
most likely assumes that all SCSI requests are done then.
In fact, scsi_device_purge_requests() already contains a blk_drain(),
but this will not fully await scsi_device_for_each_req_async(), only the
I/O requests it potentially cancels (not the non-I/O requests).
However, we can have scsi_device_for_each_req_async() increment the BB
in-flight counter, and have scsi_device_for_each_req_async_bh()
decrement it when it is done. This way, the blk_drain() will fully
await all SCSI requests to be purged.
This also removes the need for scsi_device_for_each_req_async_bh() to
double-check the current context and potentially re-schedule itself,
should it now differ from the BB's context: Changing a BB's AioContext
with a root node is done through bdrv_try_change_aio_context(), which
creates a drained section. With this patch, we keep the BB in-flight
counter elevated throughout, so we know the BB's context cannot change.
Signed-off-by: Hanna Czenczek <hreitz@redhat.com>
Message-ID: <20240202144755.671354-3-hreitz@redhat.com>
Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com>
Reviewed-by: Kevin Wolf <kwolf@redhat.com>
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
Commit: c645bac4e06bf9642cc8e339d027a5d6ec54d811
https://github.com/qemu/qemu/commit/c645bac4e06bf9642cc8e339d027a5d6ec54d811
Author: Daniel P. Berrangé <berrange@redhat.com>
Date: 2024-02-07 (Wed, 07 Feb 2024)
Changed paths:
M tests/qemu-iotests/check
Log Message:
-----------
iotests: fix leak of tmpdir in dry-run mode
Creating an instance of the 'TestEnv' class will create a temporary
directory. This dir is only deleted, however, in the __exit__ handler
invoked by a context manager.
In dry-run mode, we don't use the TestEnv via a context manager, so
were leaking the temporary directory. Since meson invokes 'check'
5 times on each configure run, developers /tmp was filling up with
empty temporary directories.
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
Message-ID: <20240205154019.1841037-1-berrange@redhat.com>
Reviewed-by: Michael Tokarev <mjt@tls.msk.ru>
Reviewed-by: Kevin Wolf <kwolf@redhat.com>
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
Commit: 7d2faf0ce2ccc896ac56bc5ed2cdf4a55056a8bb
https://github.com/qemu/qemu/commit/7d2faf0ce2ccc896ac56bc5ed2cdf4a55056a8bb
Author: Daniel P. Berrangé <berrange@redhat.com>
Date: 2024-02-07 (Wed, 07 Feb 2024)
Changed paths:
M tests/qemu-iotests/testenv.py
Log Message:
-----------
iotests: give tempdir an identifying name
If something goes wrong causing the iotests not to cleanup their
temporary directory, it is useful if the dir had an identifying
name to show what is to blame.
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
Message-ID: <20240205155158.1843304-1-berrange@redhat.com>
Revieved-by: Michael Tokarev <mjt@tls.msk.ru>
Reviewed-by: Kevin Wolf <kwolf@redhat.com>
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
Commit: b3d9bb9a560316b125dae5fb18924523d004d3dd
https://github.com/qemu/qemu/commit/b3d9bb9a560316b125dae5fb18924523d004d3dd
Author: Stefan Hajnoczi <stefanha@redhat.com>
Date: 2024-02-07 (Wed, 07 Feb 2024)
Changed paths:
M hw/block/virtio-blk.c
Log Message:
-----------
virtio-blk: do not use C99 mixed declarations
QEMU's coding style generally forbids C99 mixed declarations.
Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
Message-ID: <20240206140410.65650-1-stefanha@redhat.com>
Reviewed-by: Hanna Czenczek <hreitz@redhat.com>
Reviewed-by: Kevin Wolf <kwolf@redhat.com>
Acked-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
Commit: 3089637461693837cafd2709ef36d0cf6a4a8ed8
https://github.com/qemu/qemu/commit/3089637461693837cafd2709ef36d0cf6a4a8ed8
Author: Kevin Wolf <kwolf@redhat.com>
Date: 2024-02-07 (Wed, 07 Feb 2024)
Changed paths:
M hw/scsi/scsi-bus.c
M hw/usb/dev-storage-classic.c
M include/hw/scsi/scsi.h
Log Message:
-----------
scsi: Don't ignore most usb-storage properties
usb-storage is for the most part just a wrapper around an internally
created scsi-disk device. It uses DEFINE_BLOCK_PROPERTIES() to offer all
of the usual block device properties to the user, but then only forwards
a few select properties to the internal device while the rest is
silently ignored.
This changes scsi_bus_legacy_add_drive() to accept a whole BlockConf
instead of some individual values inside of it so that usb-storage can
now pass the whole configuration to the internal scsi-disk. This enables
the remaining block device properties, e.g. logical/physical_block_size
or discard_granularity.
Buglink: https://issues.redhat.com/browse/RHEL-22375
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
Message-ID: <20240131130607.24117-1-kwolf@redhat.com>
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
Commit: 10b2393e5e7f4c1d633f1ac8578465681c333efb
https://github.com/qemu/qemu/commit/10b2393e5e7f4c1d633f1ac8578465681c333efb
Author: Kevin Wolf <kwolf@redhat.com>
Date: 2024-02-07 (Wed, 07 Feb 2024)
Changed paths:
M block/blkio.c
Log Message:
-----------
blkio: Respect memory-alignment for bounce buffer allocations
blkio_alloc_mem_region() requires that the requested buffer size is a
multiple of the memory-alignment property. If it isn't, the allocation
fails with a return value of -EINVAL.
Fix the call in blkio_resize_bounce_pool() to make sure the requested
size is properly aligned.
I observed this problem with vhost-vdpa, which requires page aligned
memory. As the virtio-blk device behind it still had 512 byte blocks, we
got bs->bl.request_alignment = 512, but actually any request that needed
a bounce buffer and was not aligned to 4k would fail without this fix.
Suggested-by: Stefano Garzarella <sgarzare@redhat.com>
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
Message-ID: <20240131173140.42398-1-kwolf@redhat.com>
Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com>
Reviewed-by: Stefano Garzarella <sgarzare@redhat.com>
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
Commit: c42c3833e0cfdf2b80fb3ca410acfd392b6874ab
https://github.com/qemu/qemu/commit/c42c3833e0cfdf2b80fb3ca410acfd392b6874ab
Author: Hanna Czenczek <hreitz@redhat.com>
Date: 2024-02-07 (Wed, 07 Feb 2024)
Changed paths:
M hw/scsi/virtio-scsi.c
Log Message:
-----------
virtio-scsi: Attach event vq notifier with no_poll
As of commit 38738f7dbbda90fbc161757b7f4be35b52205552 ("virtio-scsi:
don't waste CPU polling the event virtqueue"), we only attach an io_read
notifier for the virtio-scsi event virtqueue instead, and no polling
notifiers. During operation, the event virtqueue is typically
non-empty, but none of the buffers are intended to be used immediately.
Instead, they only get used when certain events occur. Therefore, it
makes no sense to continuously poll it when non-empty, because it is
supposed to be and stay non-empty.
We do this by using virtio_queue_aio_attach_host_notifier_no_poll()
instead of virtio_queue_aio_attach_host_notifier() for the event
virtqueue.
Commit 766aa2de0f29b657148e04599320d771c36fd126 ("virtio-scsi: implement
BlockDevOps->drained_begin()") however has virtio_scsi_drained_end() use
virtio_queue_aio_attach_host_notifier() for all virtqueues, including
the event virtqueue. This can lead to it being polled again, undoing
the benefit of commit 38738f7dbbda90fbc161757b7f4be35b52205552.
Fix it by using virtio_queue_aio_attach_host_notifier_no_poll() for the
event virtqueue.
Reported-by: Fiona Ebner <f.ebner@proxmox.com>
Fixes: 766aa2de0f29b657148e04599320d771c36fd126
("virtio-scsi: implement BlockDevOps->drained_begin()")
Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com>
Tested-by: Fiona Ebner <f.ebner@proxmox.com>
Reviewed-by: Fiona Ebner <f.ebner@proxmox.com>
Signed-off-by: Hanna Czenczek <hreitz@redhat.com>
Message-ID: <20240202153158.788922-2-hreitz@redhat.com>
Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com>
Reviewed-by: Kevin Wolf <kwolf@redhat.com>
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
Commit: 5bdbaebcce18fe6a627cafad2043ec08f3de5744
https://github.com/qemu/qemu/commit/5bdbaebcce18fe6a627cafad2043ec08f3de5744
Author: Hanna Czenczek <hreitz@redhat.com>
Date: 2024-02-07 (Wed, 07 Feb 2024)
Changed paths:
M hw/virtio/virtio.c
M include/block/aio.h
Log Message:
-----------
virtio: Re-enable notifications after drain
During drain, we do not care about virtqueue notifications, which is why
we remove the handlers on it. When removing those handlers, whether vq
notifications are enabled or not depends on whether we were in polling
mode or not; if not, they are enabled (by default); if so, they have
been disabled by the io_poll_start callback.
Because we do not care about those notifications after removing the
handlers, this is fine. However, we have to explicitly ensure they are
enabled when re-attaching the handlers, so we will resume receiving
notifications. We do this in virtio_queue_aio_attach_host_notifier*().
If such a function is called while we are in a polling section,
attaching the notifiers will then invoke the io_poll_start callback,
re-disabling notifications.
Because we will always miss virtqueue updates in the drained section, we
also need to poll the virtqueue once after attaching the notifiers.
Buglink: https://issues.redhat.com/browse/RHEL-3934
Signed-off-by: Hanna Czenczek <hreitz@redhat.com>
Message-ID: <20240202153158.788922-3-hreitz@redhat.com>
Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com>
Reviewed-by: Kevin Wolf <kwolf@redhat.com>
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
Commit: 52bff01f64eec017ffb0d5903a0ee1d67ca7a548
https://github.com/qemu/qemu/commit/52bff01f64eec017ffb0d5903a0ee1d67ca7a548
Author: Hanna Czenczek <hreitz@redhat.com>
Date: 2024-02-07 (Wed, 07 Feb 2024)
Changed paths:
M hw/block/virtio-blk.c
Log Message:
-----------
virtio-blk: Use ioeventfd_attach in start_ioeventfd
Commit d3f6f294aeadd5f88caf0155e4360808c95b3146 ("virtio-blk: always set
ioeventfd during startup") has made virtio_blk_start_ioeventfd() always
kick the virtqueue (set the ioeventfd), regardless of whether the BB is
drained. That is no longer necessary, because attaching the host
notifier will now set the ioeventfd, too; this happens either
immediately right here in virtio_blk_start_ioeventfd(), or later when
the drain ends, in virtio_blk_ioeventfd_attach().
With event_notifier_set() removed, the code becomes the same as the one
in virtio_blk_ioeventfd_attach(), so we can reuse that function.
Signed-off-by: Hanna Czenczek <hreitz@redhat.com>
Message-ID: <20240202153158.788922-4-hreitz@redhat.com>
Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com>
Reviewed-by: Kevin Wolf <kwolf@redhat.com>
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
Commit: bfa36802d1704fc413c590ebdcc4e5ae0eacf439
https://github.com/qemu/qemu/commit/bfa36802d1704fc413c590ebdcc4e5ae0eacf439
Author: Stefan Hajnoczi <stefanha@redhat.com>
Date: 2024-02-08 (Thu, 08 Feb 2024)
Changed paths:
M hw/block/virtio-blk.c
Log Message:
-----------
virtio-blk: avoid using ioeventfd state in irqfd conditional
Requests that complete in an IOThread use irqfd to notify the guest
while requests that complete in the main loop thread use the traditional
qdev irq code path. The reason for this conditional is that the irq code
path requires the BQL:
if (s->ioeventfd_started && !s->ioeventfd_disabled) {
virtio_notify_irqfd(vdev, req->vq);
} else {
virtio_notify(vdev, req->vq);
}
There is a corner case where the conditional invokes the irq code path
instead of the irqfd code path:
static void virtio_blk_stop_ioeventfd(VirtIODevice *vdev)
{
...
/*
* Set ->ioeventfd_started to false before draining so that host notifiers
* are not detached/attached anymore.
*/
s->ioeventfd_started = false;
/* Wait for virtio_blk_dma_restart_bh() and in flight I/O to complete */
blk_drain(s->conf.conf.blk);
During blk_drain() the conditional produces the wrong result because
ioeventfd_started is false.
Use qemu_in_iothread() instead of checking the ioeventfd state.
Cc: qemu-stable@nongnu.org
Buglink: https://issues.redhat.com/browse/RHEL-15394
Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
Message-ID: <20240122172625.415386-1-stefanha@redhat.com>
Reviewed-by: Kevin Wolf <kwolf@redhat.com>
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
Commit: e2beaf7bad96c7e458f08eee033351e6b83032b2
https://github.com/qemu/qemu/commit/e2beaf7bad96c7e458f08eee033351e6b83032b2
Author: Peter Maydell <peter.maydell@linaro.org>
Date: 2024-02-08 (Thu, 08 Feb 2024)
Changed paths:
M block/blkio.c
M block/block-backend.c
M hw/block/virtio-blk.c
M hw/scsi/scsi-bus.c
M hw/scsi/virtio-scsi.c
M hw/usb/dev-storage-classic.c
M hw/virtio/virtio.c
M include/block/aio.h
M include/hw/scsi/scsi.h
M include/hw/virtio/virtio-blk.h
M qapi/qmp-dispatch.c
M tests/qemu-iotests/check
M tests/qemu-iotests/testenv.py
Log Message:
-----------
Merge tag 'for-upstream' of https://repo.or.cz/qemu/kevin into staging
Block layer patches
- Allow concurrent BB context changes
- virtio: Re-enable notifications after drain
- virtio-blk: Fix missing use of irqfd
- scsi: Don't ignore most usb-storage properties
- blkio: Respect memory-alignment for bounce buffer allocations
- iotests tmpdir fixes
- virtio-blk: Code cleanups
# -----BEGIN PGP SIGNATURE-----
#
# iQJFBAABCAAvFiEE3D3rFZqa+V09dFb+fwmycsiPL9YFAmXEkwgRHGt3b2xmQHJl
# ZGhhdC5jb20ACgkQfwmycsiPL9Y3jA//TmSBVqHljauyImYOgCt8qCXACttV0xhQ
# Q5ldUNx/JmIFMoUR7OlpVAL2MtvdwE0jjY+sDlEmWtz4IFJcCsCTUCHZZb8blreb
# +mnMkqrQ6Nb3tPR2jeIknrXqNy1ffyjZItktjWXVcl6jaHB8YabHHqszs9DIaf4n
# lcKovBKxula8ckMgvm48wCwTtS7VEPeuC5FrOqUqTtuhg+QKp5ZVoyVFHtf6GKTD
# iuXzCd4yxu4fDKAthJJj4N1bQaOmCKU7K9N/665wj9P2TyfmwlBAfNwNAlYbdX1E
# Sv7eSioQs2+oUxmfD/PUsF7wTYtDCrSAUFn1kP/XdRyXPJR3dHGiBKV9w9CaWNrU
# y8rqOhxVcuoBLRljTF32BK4HniAREjRngtpT2FnQQIyedZrXIwyTAWjs+LW12T6O
# NMiU603Nl9ZYhO1et2+qspsVpNIfEpQWpK+OCon6E+ggj1ea+pfqU30VPx4JU05I
# VLiydluIbehSkRlTHgFcTgApmx843OGW7CvWfRyen86Cexgx3DEjJUQ4/bYqaCha
# yLIi91rToSDmtlzJrg9eYiMs5Y6vz+ORvvX5im1RlbUUb7Kx/LaA4BU/uArEbBt8
# xXm/grO4hFUGqtLgd2LIjWaHSsLoW4jKeEiExFUUfvH5DG9Zl5HmzFwu+DYxX+im
# MJLLetDJAWI=
# =8tc0
# -----END PGP SIGNATURE-----
# gpg: Signature made Thu 08 Feb 2024 08:38:32 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:
virtio-blk: avoid using ioeventfd state in irqfd conditional
virtio-blk: Use ioeventfd_attach in start_ioeventfd
virtio: Re-enable notifications after drain
virtio-scsi: Attach event vq notifier with no_poll
blkio: Respect memory-alignment for bounce buffer allocations
scsi: Don't ignore most usb-storage properties
virtio-blk: do not use C99 mixed declarations
iotests: give tempdir an identifying name
iotests: fix leak of tmpdir in dry-run mode
scsi: Await request purging
block-backend: Allow concurrent context changes
monitor: use aio_co_reschedule_self()
virtio-blk: declare VirtIOBlock::rq with a type
virtio-blk: add vq_rq[] bounds check in virtio_blk_dma_restart_cb()
virtio-blk: clarify that there is at least 1 virtqueue
virtio-blk: enforce iothread-vq-mapping validation
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Compare: https://github.com/qemu/qemu/compare/03e4bc0bc027...e2beaf7bad96