qemu/hw/block/dataplane, branch master

virtio-blk: move dataplane code into virtio-blk.c

2024-01-26T10:16:58Z

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 Message-ID: <20240119135748.270944-2-stefanha@redhat.com> Reviewed-by: Kevin Wolf Signed-off-by: Kevin Wolf

Rename "QEMU global mutex" to "BQL" in comments and docs

2024-01-08T15:45:43Z

The term "QEMU global mutex" is identical to the more widely used Big QEMU Lock ("BQL"). Update the code comments and documentation to use "BQL" instead of "QEMU global mutex". Signed-off-by: Stefan Hajnoczi Acked-by: Markus Armbruster Reviewed-by: Philippe Mathieu-Daudé Reviewed-by: Paul Durrant Reviewed-by: Akihiko Odaki Reviewed-by: Cédric Le Goater Reviewed-by: Harsh Prateek Bora Message-id: 20240102153529.486531-6-stefanha@redhat.com Signed-off-by: Stefan Hajnoczi

virtio-blk: Fix potential nullpointer read access in virtio_blk_data_plane_destroy

2023-12-25T08:01:01Z

Fixes: CID 1532828 Fixes: b6948ab01d ("virtio-blk: add iothread-vq-mapping parameter") Signed-off-by: Stefan Weil Signed-off-by: Michael Tokarev

virtio-blk: add iothread-vq-mapping parameter

2023-12-21T21:49:28Z

Add the iothread-vq-mapping parameter to assign virtqueues to IOThreads. Store the vq:AioContext mapping in the new struct VirtIOBlockDataPlane->vq_aio_context[] field and refactor the code to use the per-vq AioContext instead of the BlockDriverState's AioContext. Reimplement --device virtio-blk-pci,iothread= and non-IOThread mode by assigning all virtqueues to the IOThread and main loop's AioContext in vq_aio_context[], respectively. The comment in struct VirtIOBlockDataPlane about EventNotifiers is stale. Remove it. Signed-off-by: Stefan Hajnoczi Message-ID: <20231220134755.814917-5-stefanha@redhat.com> Signed-off-by: Kevin Wolf

block: remove AioContext locking

2023-12-21T21:49:27Z

This is the big patch that removes aio_context_acquire()/aio_context_release() from the block layer and affected block layer users. There isn't a clean way to split this patch and the reviewers are likely the same group of people, so I decided to do it in one patch. Signed-off-by: Stefan Hajnoczi Reviewed-by: Eric Blake Reviewed-by: Kevin Wolf Reviewed-by: Paul Durrant Message-ID: <20231205182011.1976568-7-stefanha@redhat.com> Signed-off-by: Kevin Wolf

virtio-blk: remove batch notification BH

2023-10-31T14:42:17Z

There is a batching mechanism for virtio-blk Used Buffer Notifications that is no longer needed because the previous commit added batching to virtio_notify_irqfd(). Note that this mechanism was rarely used in practice because it is only enabled when EVENT_IDX is not negotiated by the driver. Modern drivers enable EVENT_IDX. Reviewed-by: Eric Blake Signed-off-by: Stefan Hajnoczi Message-ID: <20230913200045.1024233-5-stefanha@redhat.com> Reviewed-by: Michael S. Tsirkin Reviewed-by: Kevin Wolf Signed-off-by: Kevin Wolf

util/defer-call: move defer_call() to util/

2023-10-31T14:41:42Z

The networking subsystem may wish to use defer_call(), so move the code to util/ where it can be reused. As a reminder of what defer_call() does: This API defers a function call within a defer_call_begin()/defer_call_end() section, allowing multiple calls to batch up. This is a performance optimization that is used in the block layer to submit several I/O requests at once instead of individually: defer_call_begin(); <-- start of section ... defer_call(my_func, my_obj); <-- deferred my_func(my_obj) call defer_call(my_func, my_obj); <-- another defer_call(my_func, my_obj); <-- another ... defer_call_end(); <-- end of section, my_func(my_obj) is called once Suggested-by: Ilya Maximets Reviewed-by: Philippe Mathieu-Daudé Signed-off-by: Stefan Hajnoczi Message-ID: <20230913200045.1024233-3-stefanha@redhat.com> Reviewed-by: Michael S. Tsirkin Reviewed-by: Kevin Wolf Signed-off-by: Kevin Wolf

block: rename blk_io_plug_call() API to defer_call()

2023-10-31T14:41:24Z

Prepare to move the blk_io_plug_call() API out of the block layer so that other subsystems call use this deferred call mechanism. Rename it to defer_call() but leave the code in block/plug.c. The next commit will move the code out of the block layer. Suggested-by: Ilya Maximets Reviewed-by: Philippe Mathieu-Daudé Reviewed-by: Paul Durrant Signed-off-by: Stefan Hajnoczi Message-ID: <20230913200045.1024233-2-stefanha@redhat.com> Reviewed-by: Michael S. Tsirkin Reviewed-by: Kevin Wolf Signed-off-by: Kevin Wolf

virtio-blk: fix host notifier issues during dataplane start/stop

2023-07-12T19:20:32Z

The main loop thread can consume 100% CPU when using --device virtio-blk-pci,iothread=. ppoll() constantly returns but reading virtqueue host notifiers fails with EAGAIN. The file descriptors are stale and remain registered with the AioContext because of bugs in the virtio-blk dataplane start/stop code. The problem is that the dataplane start/stop code involves drain operations, which call virtio_blk_drained_begin() and virtio_blk_drained_end() at points where the host notifier is not operational: - In virtio_blk_data_plane_start(), blk_set_aio_context() drains after vblk->dataplane_started has been set to true but the host notifier has not been attached yet. - In virtio_blk_data_plane_stop(), blk_drain() and blk_set_aio_context() drain after the host notifier has already been detached but with vblk->dataplane_started still set to true. I would like to simplify ->ioeventfd_start/stop() to avoid interactions with drain entirely, but couldn't find a way to do that. Instead, this patch accepts the fragile nature of the code and reorders it so that vblk->dataplane_started is false during drain operations. This way the virtio_blk_drained_begin() and virtio_blk_drained_end() calls don't touch the host notifier. The result is that virtio_blk_data_plane_start() and virtio_blk_data_plane_stop() have complete control over the host notifier and stale file descriptors are no longer left in the AioContext. This patch fixes the 100% CPU consumption in the main loop thread and correctly moves host notifier processing to the IOThread. Fixes: 1665d9326fd2 ("virtio-blk: implement BlockDevOps->drained_begin()") Reported-by: Lukáš Doktor Signed-off-by: Stefan Hajnoczi Tested-by: Lukas Doktor Message-id: 20230704151527.193586-1-stefanha@redhat.com Signed-off-by: Stefan Hajnoczi

hw/virtio: Build various target-agnostic objects just once

2023-06-23T06:54:44Z

The previous commit remove the unnecessary "virtio-access.h" header. These files no longer have target-specific dependency. Move them to the generic 'softmmu_ss' source set. Signed-off-by: Philippe Mathieu-Daudé Reviewed-by: Richard Henderson Reviewed-by: Thomas Huth Message-Id: <20230524093744.88442-11-philmd@linaro.org> Reviewed-by: Michael S. Tsirkin Signed-off-by: Michael S. Tsirkin