docs/devel/replay.rst

21 Devices' models that have non-deterministic input from external devices were
57 can predict when to inject that event using the instruction counter.
65 system emulation. As it is important that batches of events are kept
99 of time. That's why we do not process a group of timers until the checkpoint
106 (called the warp timer) on the virtual real time clock, so that the
115 and it warps the virtual clock by the amount of real time that has passed
121 Record/replay mechanism, that could be enabled through icount mode, expects
123 everything that affects
132  * Real time clock. Based on host time and used only for callbacks that
137    That is why it is completely deterministic and does not have to be recorded.
138  * Host clock. This clock is used by device models that simulate real time
147 All virtual devices should use virtual clock for timers that change the guest
151 Virtual devices can also use realtime clock for the events that do not change
155 the virtual devices (e.g., slirp routing device) that lie outside the
173 Bottom half callbacks, that affect the guest state, should be invoked through
180 disk state. But callbacks that virtual disk controller uses for reading and
188 replaying process because main loop also processes the events that do not
191 That is why we had to implement saving and replaying bottom halves callbacks
212 is not defined. It means that you should not call functions like
214 the dependencies that may make restoring the VM state non-deterministic.
220 of the network connections, that could be broken by the remote timeouts).
222 after that stop should not break the replay by the unneeded guest state change.
237 that perform operations with virtual hardware. These operations may change
244 Here is the list of events that are written into the log:
257        callbacks that affect virtual machine state, but normally called
296     - Array with bytes that were read.