aboutsummaryrefslogtreecommitdiff
path: root/replay/replay.c
diff options
context:
space:
mode:
authorAlex Bennée <alex.bennee@linaro.org>2023-12-11 09:13:40 +0000
committerAlex Bennée <alex.bennee@linaro.org>2024-01-08 13:58:59 +0000
commit1f881ea4a444ef36a8b6907b0b82be4b3af253a2 (patch)
tree293e39ea7b4ae481893b5f0200822408af7c595b /replay/replay.c
parentfd84325f71254c741464de231c491d21ecf63b1a (diff)
replay: stop us hanging in rr_wait_io_event
A lot of the hang I see are when we end up spinning in rr_wait_io_event for an event that will never come in playback. As a new check functions which can see if we are in PLAY mode and kick us us the wait function so the event can be processed. This fixes most of the failures in replay_kernel.py Fixes: https://gitlab.com/qemu-project/qemu/-/issues/2013 Cc: Pavel Dovgalyuk <pavel.dovgaluk@ispras.ru> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Signed-off-by: Alex Bennée <alex.bennee@linaro.org> Message-Id: <20231211091346.14616-12-alex.bennee@linaro.org>
Diffstat (limited to 'replay/replay.c')
-rw-r--r--replay/replay.c21
1 files changed, 21 insertions, 0 deletions
diff --git a/replay/replay.c b/replay/replay.c
index ff197f436b..3fd241a4fc 100644
--- a/replay/replay.c
+++ b/replay/replay.c
@@ -449,6 +449,27 @@ void replay_start(void)
replay_enable_events();
}
+/*
+ * For none/record the answer is yes.
+ */
+bool replay_can_wait(void)
+{
+ if (replay_mode == REPLAY_MODE_PLAY) {
+ /*
+ * For playback we shouldn't ever be at a point we wait. If
+ * the instruction count has reached zero and we have an
+ * unconsumed event we should go around again and consume it.
+ */
+ if (replay_state.instruction_count == 0 && replay_state.has_unread_data) {
+ return false;
+ } else {
+ replay_sync_error("Playback shouldn't have to iowait");
+ }
+ }
+ return true;
+}
+
+
void replay_finish(void)
{
if (replay_mode == REPLAY_MODE_NONE) {