docs/devel/replay.rst

12 Record/replay functions are used for the deterministic replay of qemu
23 E.g. network packets are written into the log when they arrive into the virtual
26 All non-deterministic events are coming from these devices. But to
65 system emulation. As it is important that batches of events are kept
67 while instruction checkpoints are written by the vCPU thread) we need
76 While the unlocks are usually in the reverse order, this is not
85 non-determinism. These are inputs from clock and peripheral devices,
89 Invocations of timers are coupled with clock reads and changing the state
95 Checkpoints here do not refer to virtual machine snapshots. They are just
110 Two functions are used for this purpose; because these actions change
112 checkpoint. ``icount_start_warp_timer`` checks if the CPUs are idle and if so
129 Timers are used to execute callbacks from different subsystems of QEMU
130 at the specified moments of time. There are several kinds of timers:
148 state. Virtual clock is deterministic, therefore such timers are deterministic
164 All block completion operations are added to the queue in the coroutines.
167 events read from the log. Therefore block devices requests are processed
175 Their invocations are saved in record mode and synchronized with the existing
178 Disk I/O events are completely deterministic in our model, because
184 Reading and writing requests are created by CPU thread of QEMU. Later these
186 halves consist of callback and its parameters. They are processed when
187 main loop locks the BQL. These locks are not synchronized with
194 log when its callbacks are executed. In replay mode callbacks are not processed
199 case bottom halves are not marked as "replayable" and do not saved
236 Synchronization marks (checkpoints) are used for synchronizing qemu threads
244 Here is the list of events that are written into the log: