]> git.ipfire.org Git - thirdparty/qemu.git/commit
virtio-scsi: introduce event and ctrl virtqueue locks
authorStefan Hajnoczi <stefanha@redhat.com>
Tue, 11 Mar 2025 13:26:08 +0000 (21:26 +0800)
committerKevin Wolf <kwolf@redhat.com>
Thu, 13 Mar 2025 16:57:23 +0000 (17:57 +0100)
commitb348ca2e043c0f7c9ecc1bbbd7dd87db47887e9f
treee9c26a542a03226f2c38a81fe70f058a7184c292
parent1cf18cc9bf5e9f88ad92f89886652e0361e2f41f
virtio-scsi: introduce event and ctrl virtqueue locks

Virtqueues are not thread-safe. Until now this was not a major issue
since all virtqueue processing happened in the same thread. The ctrl
queue's Task Management Function (TMF) requests sometimes need the main
loop, so a BH was used to schedule the virtqueue completion back in the
thread that has virtqueue access.

When IOThread Virtqueue Mapping is introduced in later commits, event
and ctrl virtqueue accesses from other threads will become necessary.
Introduce an optional per-virtqueue lock so the event and ctrl
virtqueues can be protected in the commits that follow.

The addition of the ctrl virtqueue lock makes
virtio_scsi_complete_req_from_main_loop() and its BH unnecessary.
Instead, take the ctrl virtqueue lock from the main loop thread.

The cmd virtqueue does not have a lock because the entirety of SCSI
command processing happens in one thread. Only one thread accesses the
cmd virtqueue and a lock is unnecessary.

Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
Reviewed-by: Kevin Wolf <kwolf@redhat.com>
Message-ID: <20250311132616.1049687-6-stefanha@redhat.com>
Tested-by: Peter Krempa <pkrempa@redhat.com>
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
hw/scsi/virtio-scsi.c
include/hw/virtio/virtio-scsi.h