xref: /qemu/docs/devel/replay.rst (revision 04d0583a4f5d00061bf57d17947aa0d5c6a6cecf)
1..
2   Copyright (c) 2022, ISP RAS
3   Written by Pavel Dovgalyuk
4
5=======================
6Execution Record/Replay
7=======================
8
9Record/replay mechanism, that could be enabled through icount mode, expects
10the virtual devices to satisfy the following requirements.
11
12The main idea behind this document is that everything that affects
13the guest state during execution in icount mode should be deterministic.
14
15Timers
16------
17
18All virtual devices should use virtual clock for timers that change the guest
19state. Virtual clock is deterministic, therefore such timers are deterministic
20too.
21
22Virtual devices can also use realtime clock for the events that do not change
23the guest state directly. When the clock ticking should depend on VM execution
24speed, use virtual clock with EXTERNAL attribute. It is not deterministic,
25but its speed depends on the guest execution. This clock is used by
26the virtual devices (e.g., slirp routing device) that lie outside the
27replayed guest.
28
29Bottom halves
30-------------
31
32Bottom half callbacks, that affect the guest state, should be invoked through
33replay_bh_schedule_event or replay_bh_schedule_oneshot_event functions.
34Their invocations are saved in record mode and synchronized with the existing
35log in replay mode.
36
37Saving/restoring the VM state
38-----------------------------
39
40All fields in the device state structure (including virtual timers)
41should be restored by loadvm to the same values they had before savevm.
42
43Avoid accessing other devices' state, because the order of saving/restoring
44is not defined. It means that you should not call functions like
45'update_irq' in post_load callback. Save everything explicitly to avoid
46the dependencies that may make restoring the VM state non-deterministic.
47
48Stopping the VM
49---------------
50
51Stopping the guest should not interfere with its state (with the exception
52of the network connections, that could be broken by the remote timeouts).
53VM can be stopped at any moment of replay by the user. Restarting the VM
54after that stop should not break the replay by the unneeded guest state change.
55