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