* [PATCH] bql: Fix bql_locked status with condvar APIs
@ 2025-09-04 22:31 Peter Xu
2025-09-08 18:24 ` Stefan Hajnoczi
` (2 more replies)
0 siblings, 3 replies; 4+ messages in thread
From: Peter Xu @ 2025-09-04 22:31 UTC (permalink / raw)
To: qemu-devel
Cc: Daniel P . Berrangé, Philippe Mathieu-Daudé,
Stefan Hajnoczi, Paolo Bonzini, Juraj Marcin, peterx,
Peter Maydell, Fabiano Rosas
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 <peterx@redhat.com>
---
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(-)
diff --git a/include/qemu/main-loop.h b/include/qemu/main-loop.h
index 4e2436b196..0d55c636b2 100644
--- a/include/qemu/main-loop.h
+++ b/include/qemu/main-loop.h
@@ -270,6 +270,24 @@ void rust_bql_mock_lock(void);
*/
bool bql_locked(void);
+/**
+ * mutex_is_bql:
+ *
+ * @mutex: the mutex pointer
+ *
+ * Returns whether the mutex is the BQL.
+ */
+bool mutex_is_bql(QemuMutex *mutex);
+
+/**
+ * bql_update_status:
+ *
+ * @locked: update status on whether the BQL is locked
+ *
+ * NOTE: this should normally only be invoked when the status changed.
+ */
+void bql_update_status(bool locked);
+
/**
* bql_block: Allow/deny releasing the BQL
*
diff --git a/util/qemu-thread-common.h b/util/qemu-thread-common.h
index 2af6b12085..09331843ba 100644
--- a/util/qemu-thread-common.h
+++ b/util/qemu-thread-common.h
@@ -14,6 +14,7 @@
#define QEMU_THREAD_COMMON_H
#include "qemu/thread.h"
+#include "qemu/main-loop.h"
#include "trace.h"
static inline void qemu_mutex_post_init(QemuMutex *mutex)
@@ -39,6 +40,9 @@ static inline void qemu_mutex_post_lock(QemuMutex *mutex,
mutex->line = line;
#endif
trace_qemu_mutex_locked(mutex, file, line);
+ if (mutex_is_bql(mutex)) {
+ bql_update_status(true);
+ }
}
static inline void qemu_mutex_pre_unlock(QemuMutex *mutex,
@@ -49,6 +53,9 @@ static inline void qemu_mutex_pre_unlock(QemuMutex *mutex,
mutex->line = 0;
#endif
trace_qemu_mutex_unlock(mutex, file, line);
+ if (mutex_is_bql(mutex)) {
+ bql_update_status(false);
+ }
}
#endif
diff --git a/stubs/iothread-lock.c b/stubs/iothread-lock.c
index 6050c081f5..c89c9c7228 100644
--- a/stubs/iothread-lock.c
+++ b/stubs/iothread-lock.c
@@ -34,3 +34,12 @@ void bql_block_unlock(bool increase)
assert((new_value > bql_unlock_blocked) == increase);
bql_unlock_blocked = new_value;
}
+
+bool mutex_is_bql(QemuMutex *mutex)
+{
+ return false;
+}
+
+void bql_update_status(bool locked)
+{
+}
diff --git a/system/cpus.c b/system/cpus.c
index 437848b5eb..9c066e1c08 100644
--- a/system/cpus.c
+++ b/system/cpus.c
@@ -524,6 +524,18 @@ bool qemu_in_vcpu_thread(void)
QEMU_DEFINE_STATIC_CO_TLS(bool, bql_locked)
+bool mutex_is_bql(QemuMutex *mutex)
+{
+ return mutex == &bql;
+}
+
+void bql_update_status(bool locked)
+{
+ /* This function should only be used when an update happened.. */
+ assert(bql_locked() != locked);
+ set_bql_locked(locked);
+}
+
static uint32_t bql_unlock_blocked;
void bql_block_unlock(bool increase)
@@ -564,14 +576,12 @@ void bql_lock_impl(const char *file, int line)
g_assert(!bql_locked());
bql_lock_fn(&bql, file, line);
- set_bql_locked(true);
}
void bql_unlock(void)
{
g_assert(bql_locked());
g_assert(!bql_unlock_blocked);
- set_bql_locked(false);
qemu_mutex_unlock(&bql);
}
--
2.50.1
^ permalink raw reply related [flat|nested] 4+ messages in thread* Re: [PATCH] bql: Fix bql_locked status with condvar APIs
2025-09-04 22:31 [PATCH] bql: Fix bql_locked status with condvar APIs Peter Xu
@ 2025-09-08 18:24 ` Stefan Hajnoczi
2025-09-22 7:19 ` Philippe Mathieu-Daudé
2025-10-09 9:21 ` Philippe Mathieu-Daudé
2 siblings, 0 replies; 4+ messages in thread
From: Stefan Hajnoczi @ 2025-09-08 18:24 UTC (permalink / raw)
To: Peter Xu
Cc: qemu-devel, Daniel P . Berrangé, Philippe Mathieu-Daudé,
Paolo Bonzini, Juraj Marcin, Peter Maydell, Fabiano Rosas
[-- Attachment #1: Type: text/plain, Size: 1464 bytes --]
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 <peterx@redhat.com>
> ---
> 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 <stefanha@redhat.com>
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [PATCH] bql: Fix bql_locked status with condvar APIs
2025-09-04 22:31 [PATCH] bql: Fix bql_locked status with condvar APIs Peter Xu
2025-09-08 18:24 ` Stefan Hajnoczi
@ 2025-09-22 7:19 ` Philippe Mathieu-Daudé
2025-10-09 9:21 ` Philippe Mathieu-Daudé
2 siblings, 0 replies; 4+ messages in thread
From: Philippe Mathieu-Daudé @ 2025-09-22 7:19 UTC (permalink / raw)
To: Peter Xu, qemu-devel
Cc: Daniel P . Berrangé, Stefan Hajnoczi, Paolo Bonzini,
Juraj Marcin, Peter Maydell, Fabiano Rosas
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 <peterx@redhat.com>
> ---
> 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: Philippe Mathieu-Daudé <philmd@linaro.org>
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [PATCH] bql: Fix bql_locked status with condvar APIs
2025-09-04 22:31 [PATCH] bql: Fix bql_locked status with condvar APIs Peter Xu
2025-09-08 18:24 ` Stefan Hajnoczi
2025-09-22 7:19 ` Philippe Mathieu-Daudé
@ 2025-10-09 9:21 ` Philippe Mathieu-Daudé
2 siblings, 0 replies; 4+ messages in thread
From: Philippe Mathieu-Daudé @ 2025-10-09 9:21 UTC (permalink / raw)
To: Peter Xu, qemu-devel
Cc: Daniel P . Berrangé, Stefan Hajnoczi, Paolo Bonzini,
Juraj Marcin, Peter Maydell, Fabiano Rosas
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 <peterx@redhat.com>
> ---
> 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.
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2025-10-09 9:22 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2025-09-04 22:31 [PATCH] bql: Fix bql_locked status with condvar APIs Peter Xu
2025-09-08 18:24 ` Stefan Hajnoczi
2025-09-22 7:19 ` Philippe Mathieu-Daudé
2025-10-09 9:21 ` Philippe Mathieu-Daudé
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).