summaryrefslogtreecommitdiffstats
path: root/hw/usb/imx-usb-phy.c
diff options
context:
space:
mode:
authorPaolo Bonzini2021-04-13 10:20:32 +0200
committerPaolo Bonzini2021-05-04 14:15:35 +0200
commit4951967d84a0acbf47895add9158e2d4c6056ea0 (patch)
treed458223a160c77b2ff7a2defca4efe6d08d9358f /hw/usb/imx-usb-phy.c
parentAdd NVMM Accelerator: add maintainers for NetBSD/NVMM (diff)
downloadqemu-4951967d84a0acbf47895add9158e2d4c6056ea0.tar.gz
qemu-4951967d84a0acbf47895add9158e2d4c6056ea0.tar.xz
qemu-4951967d84a0acbf47895add9158e2d4c6056ea0.zip
ratelimit: protect with a mutex
Right now, rate limiting is protected by the AioContext mutex, which is taken for example both by the block jobs and by qmp_block_job_set_speed (via find_block_job). We would like to remove the dependency of block layer code on the AioContext mutex, since most drivers and the core I/O code are already not relying on it. However, there is no existing lock that can easily be taken by both ratelimit_set_speed and ratelimit_calculate_delay, especially because the latter might run in coroutine context (and therefore under a CoMutex) but the former will not. Since concurrent calls to ratelimit_calculate_delay are not possible, one idea could be to use a seqlock to get a snapshot of slice_ns and slice_quota. But for now keep it simple, and just add a mutex to the RateLimit struct; block jobs are generally not performance critical to the point of optimizing the clock cycles spent in synchronization. This also requires the introduction of init/destroy functions, so add them to the two users of ratelimit.h. Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Diffstat (limited to 'hw/usb/imx-usb-phy.c')
0 files changed, 0 insertions, 0 deletions