OpenE2K/qemu-e2k
13
4
Fork 0
Code Issues 4 Pull Requests Projects 2 Releases Activity

replay: document development rules

Browse Source 
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:
Pavel Dovgalyuk 2019-07-25 11:44:21 +03:00 committed by Paolo Bonzini
parent 245429e4a0
commit 978ae0e99c
1 changed files with 46 additions and 0 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

46
docs/devel/replay.txt Normal file
View 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.