On 5/9/25 00:31, Peter Xu wrote:
QEMU has a per-thread "bql_locked" variable stored in TLS section, showing
whether the current thread is holding the BQL lock.
It's a pretty handy variable. Function-wise, QEMU have codes trying to
conditionally take bql, relying on the var reflecting the locking status
(e.g. BQL_LOCK_GUARD), or in a GDB debugging session, we could also look at
the variable (in reality, co_tls_bql_locked), to see which thread is
currently holding the bql.
When using that as a debugging facility, sometimes we can observe multiple
threads holding bql at the same time. It's because QEMU's condvar APIs
bypassed the bql_*() API, hence they do not update bql_locked even if they
have released the mutex while waiting.
It can cause confusion if one does "thread apply all p co_tls_bql_locked"
and see multiple threads reporting true.
Fix this by moving the bql status updates into the mutex debug hooks. Now
the variable should always reflect the reality.
Signed-off-by: Peter Xu <[email protected]>
---
rfc->v1
- Fix comment [Stefan]
---
include/qemu/main-loop.h | 18 ++++++++++++++++++
util/qemu-thread-common.h | 7 +++++++
stubs/iothread-lock.c | 9 +++++++++
system/cpus.c | 14 ++++++++++++--
4 files changed, 46 insertions(+), 2 deletions(-)
Patch queued, thanks.
