From c7f26ded6d5065e4116f630f6a490b55f6c5f58e Mon Sep 17 00:00:00 2001 From: Peter Maydell Date: Tue, 9 Aug 2022 10:55:14 +0100 Subject: icount: Take iothread lock when running QEMU timers The function icount_prepare_for_run() is called with the iothread unlocked, but it can call icount_notify_aio_contexts() which will run qemu timer handlers. Those are supposed to be run only with the iothread lock held, so take the lock while we do that. Since icount mode runs everything on a single thread anyway, not holding the lock is likely mostly not going to introduce races, but it can cause us to trip over assertions that we do hold the lock, such as the one reported in issue 1130. Resolves: https://gitlab.com/qemu-project/qemu/-/issues/1130 Signed-off-by: Peter Maydell Reviewed-by: Richard Henderson Tested-by: Pavel Dovgalyuk Message-id: 20220801164527.3134765-1-peter.maydell@linaro.org --- accel/tcg/tcg-accel-ops-icount.c | 6 ++++++ 1 file changed, 6 insertions(+) (limited to 'accel/tcg/tcg-accel-ops-icount.c') diff --git a/accel/tcg/tcg-accel-ops-icount.c b/accel/tcg/tcg-accel-ops-icount.c index 8f1dda4..84cc742 100644 --- a/accel/tcg/tcg-accel-ops-icount.c +++ b/accel/tcg/tcg-accel-ops-icount.c @@ -109,7 +109,13 @@ void icount_prepare_for_run(CPUState *cpu) replay_mutex_lock(); if (cpu->icount_budget == 0) { + /* + * We're called without the iothread lock, so must take it while + * we're calling timer handlers. + */ + qemu_mutex_lock_iothread(); icount_notify_aio_contexts(); + qemu_mutex_unlock_iothread(); } } -- cgit v1.1