On Thu, Sep 04, 2025 at 06:31:58PM -0400, 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(-)
Reviewed-by: Stefan Hajnoczi <[email protected]>
signature.asc
Description: PGP signature
