aboutsummaryrefslogtreecommitdiff
path: root/docs/replay.txt
diff options
context:
space:
mode:
authorAlex Bennée <alex.bennee@linaro.org>2018-02-27 12:52:48 +0300
committerPaolo Bonzini <pbonzini@redhat.com>2018-03-12 17:10:36 +0100
commitd759c951f3287fad04210a52f2dc93f94cf58c7f (patch)
tree5af67500a854ba2e25bc7690bf346bf3c2bbb810 /docs/replay.txt
parent1a423896fa4fc2ea49c64e7a493d88a8b251950d (diff)
downloadqemu-d759c951f3287fad04210a52f2dc93f94cf58c7f.zip
qemu-d759c951f3287fad04210a52f2dc93f94cf58c7f.tar.gz
qemu-d759c951f3287fad04210a52f2dc93f94cf58c7f.tar.bz2
replay: push replay_mutex_lock up the call tree
Now instead of using the replay_lock to guard the output of the log we now use it to protect the whole execution section. This replaces what the BQL used to do when it was held during TCG execution. We also introduce some rules for locking order - mainly that you cannot take the replay_mutex while holding the BQL. This leads to some slight sophistry during start-up and extending the replay_mutex_destroy function to unlock the mutex without checking for the BQL condition so it can be cleanly dropped in the non-replay case. Signed-off-by: Alex Bennée <alex.bennee@linaro.org> Signed-off-by: Pavel Dovgalyuk <pavel.dovgaluk@ispras.ru> Tested-by: Pavel Dovgalyuk <pavel.dovgaluk@ispras.ru> Message-Id: <20180227095248.1060.40374.stgit@pasha-VirtualBox> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> Signed-off-by: Alex Bennée <alex.bennee@linaro.org>
Diffstat (limited to 'docs/replay.txt')
-rw-r--r--docs/replay.txt22
1 files changed, 22 insertions, 0 deletions
diff --git a/docs/replay.txt b/docs/replay.txt
index c52407f..959633e 100644
--- a/docs/replay.txt
+++ b/docs/replay.txt
@@ -49,6 +49,28 @@ Modifications of qemu include:
* recording/replaying user input (mouse and keyboard)
* adding internal checkpoints for cpu and io synchronization
+Locking and thread synchronisation
+----------------------------------
+
+Previously the synchronisation of the main thread and the vCPU thread
+was ensured by the holding of the BQL. However the trend has been to
+reduce the time the BQL was held across the system including under TCG
+system emulation. As it is important that batches of events are kept
+in sequence (e.g. expiring timers and checkpoints in the main thread
+while instruction checkpoints are written by the vCPU thread) we need
+another lock to keep things in lock-step. This role is now handled by
+the replay_mutex_lock. It used to be held only for each event being
+written but now it is held for a whole execution period. This results
+in a deterministic ping-pong between the two main threads.
+
+As the BQL is now a finer grained lock than the replay_lock it is almost
+certainly a bug, and a source of deadlocks, to take the
+replay_mutex_lock while the BQL is held. This is enforced by an assert.
+While the unlocks are usually in the reverse order, this is not
+necessary; you can drop the replay_lock while holding the BQL, without
+doing a more complicated unlock_iothread/replay_unlock/lock_iothread
+sequence.
+
Non-deterministic events
------------------------