978ae0e99c
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>
47 lines
1.9 KiB
Plaintext
47 lines
1.9 KiB
Plaintext
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.
|