diff options
author | Pavel Dovgalyuk <Pavel.Dovgaluk@ispras.ru> | 2019-07-25 11:44:21 +0300 |
---|---|---|
committer | Paolo Bonzini <pbonzini@redhat.com> | 2019-08-20 17:26:21 +0200 |
commit | 978ae0e99c1760c228eef2d320386daab3bf5b10 (patch) | |
tree | 4bf7dcfb27b5af5b926541cb30a95444aae26a07 /docs/devel | |
parent | 245429e4a0e036471ba46e2393b6f33b78b9615e (diff) |
replay: document development rules
This patch introduces docs/devel/replay.txt which describes the rules
that should be followed to make virtual devices usable in record/replay mode.
Signed-off-by: Pavel Dovgalyuk <Pavel.Dovgauk@ispras.ru>
--
v9: fixed external virtual clock description (reported by Artem Pisarenko)
Message-Id: <156404426119.18669.6707258931552832854.stgit@pasha-Precision-3630-Tower>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Signed-off-by: Pavel Dovgalyuk <Pavel.Dovgaluk@ispras.ru>
Diffstat (limited to 'docs/devel')
-rw-r--r-- | docs/devel/replay.txt | 46 |
1 files changed, 46 insertions, 0 deletions
diff --git a/docs/devel/replay.txt b/docs/devel/replay.txt new file mode 100644 index 0000000000..e641c35add --- /dev/null +++ b/docs/devel/replay.txt @@ -0,0 +1,46 @@ +Record/replay mechanism, that could be enabled through icount mode, expects +the virtual devices to satisfy the following requirements. + +The main idea behind this document is that everything that affects +the guest state during execution in icount mode should be deterministic. + +Timers +====== + +All virtual devices should use virtual clock for timers that change the guest +state. Virtual clock is deterministic, therefore such timers are deterministic +too. + +Virtual devices can also use realtime clock for the events that do not change +the guest state directly. When the clock ticking should depend on VM execution +speed, use virtual clock with EXTERNAL attribute. It is not deterministic, +but its speed depends on the guest execution. This clock is used by +the virtual devices (e.g., slirp routing device) that lie outside the +replayed guest. + +Bottom halves +============= + +Bottom half callbacks, that affect the guest state, should be invoked through +replay_bh_schedule_event or replay_bh_schedule_oneshot_event functions. +Their invocations are saved in record mode and synchronized with the existing +log in replay mode. + +Saving/restoring the VM state +============================= + +All fields in the device state structure (including virtual timers) +should be restored by loadvm to the same values they had before savevm. + +Avoid accessing other devices' state, because the order of saving/restoring +is not defined. It means that you should not call functions like +'update_irq' in post_load callback. Save everything explicitly to avoid +the dependencies that may make restoring the VM state non-deterministic. + +Stopping the VM +=============== + +Stopping the guest should not interfere with its state (with the exception +of the network connections, that could be broken by the remote timeouts). +VM can be stopped at any moment of replay by the user. Restarting the VM +after that stop should not break the replay by the unneeded guest state change. |