mirror of
https://github.com/Motorhead1991/qemu.git
synced 2025-12-25 17:08:36 -07:00
b348ca2e04
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> |
||
|---|---|---|
| .. | ||
| accel | ||
| authz | ||
| block | ||
| chardev | ||
| crypto | ||
| disas | ||
| exec | ||
| fpu | ||
| gdbstub | ||
| hw | ||
| io | ||
| libdecnumber | ||
| migration | ||
| monitor | ||
| net | ||
| qapi | ||
| qemu | ||
| qobject | ||
| qom | ||
| scsi | ||
| semihosting | ||
| standard-headers | ||
| system | ||
| tcg | ||
| ui | ||
| user | ||
| elf.h | ||
| glib-compat.h | ||
| qemu-io.h | ||
| qemu-main.h | ||