docs/devel/replay.rst

3    Written by Pavel Dovgalyuk and Alex Bennée
28 these moments by counting the number of instructions executed between
63 was ensured by the holding of the BQL. However the trend has been to
67 while instruction checkpoints are written by the vCPU thread) we need
68 another lock to keep things in lock-step. This role is now handled by
75 replay_mutex_lock while the BQL is held. This is enforced by an assert.
84 Replaying the execution of virtual machine is bound by sources of
105 1 ns per *real time* nanosecond.  This is done by setting up a timer
115 and it warps the virtual clock by the amount of real time that has passed
138  * Host clock. This clock is used by device models that simulate real time
154 but its speed depends on the guest execution. This clock is used by
184 Reading and writing requests are created by CPU thread of QEMU. Later these
209 should be restored by loadvm to the same values they had before savevm.
220 of the network connections, that could be broken by the remote timeouts).
221 VM can be stopped at any moment of replay by the user. Restarting the VM
222 after that stop should not break the replay by the unneeded guest state change.
230 using replay log created by another build of qemu.
246  - EVENT_INSTRUCTION. Instructions executed since last event. Followed by:
258        asynchronously. Followed by:
264        (key press/release, mouse pointer movement). Followed by:
270        initiated by the sender. Followed by:
276        operations with disk and flash drives with CPU. Followed by:
280      - REPLAY_ASYNC_EVENT_NET. Incoming network packet. Followed by:
287    e.g., by closing the window.
288  - EVENT_CHAR_WRITE. Used to synchronize character output operations. Followed by:
294    initiated by qemu. Followed by:
299    initiated by qemu. Followed by:
303  - EVENT_CLOCK + clock_id. Group of events for host clock read operations. Followed by: