mirror of
https://gitlab.com/qemu-project/qemu
synced 2024-09-06 01:43:39 +00:00
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>
This commit is contained in:
parent
245429e4a0
commit
978ae0e99c
46
docs/devel/replay.txt
Normal file
46
docs/devel/replay.txt
Normal file
|
@ -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.
|
Loading…
Reference in a new issue