replay: document development rules

Record/replay mechanism, that could be enabled through icount mode, expects

the virtual devices to satisfy the following requirements.

The main idea behind this document is that everything that affects

the guest state during execution in icount mode should be deterministic.

Timers

======

All virtual devices should use virtual clock for timers that change the guest

state. Virtual clock is deterministic, therefore such timers are deterministic

too.

Virtual devices can also use realtime clock for the events that do not change

the guest state directly. When the clock ticking should depend on VM execution

speed, use virtual clock with EXTERNAL attribute. It is not deterministic,

but its speed depends on the guest execution. This clock is used by

the virtual devices (e.g., slirp routing device) that lie outside the

replayed guest.

Bottom halves

=============

Bottom half callbacks, that affect the guest state, should be invoked through

replay_bh_schedule_event or replay_bh_schedule_oneshot_event functions.

Their invocations are saved in record mode and synchronized with the existing

log in replay mode.

Saving/restoring the VM state

=============================

All fields in the device state structure (including virtual timers)

should be restored by loadvm to the same values they had before savevm.

Avoid accessing other devices' state, because the order of saving/restoring

is not defined. It means that you should not call functions like

'update_irq' in post_load callback. Save everything explicitly to avoid

the dependencies that may make restoring the VM state non-deterministic.

Stopping the VM

===============

Stopping the guest should not interfere with its state (with the exception

of the network connections, that could be broken by the remote timeouts).

VM can be stopped at any moment of replay by the user. Restarting the VM

after that stop should not break the replay by the unneeded guest state change.