04d0583a4f
This patch converts prior .txt replay devel documentation to .rst. Signed-off-by: Pavel Dovgalyuk <Pavel.Dovgalyuk@ispras.ru> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Message-Id: <165364839013.688121.11935249420738873044.stgit@pasha-ThinkPad-X280> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
55 lines
2.0 KiB
ReStructuredText
55 lines
2.0 KiB
ReStructuredText
..
|
|
Copyright (c) 2022, ISP RAS
|
|
Written by Pavel Dovgalyuk
|
|
|
|
=======================
|
|
Execution Record/Replay
|
|
=======================
|
|
|
|
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.
|