docs/devel: Mention post_load hook restrictions where we document the hook

Accessing another device in a post_load hook is a bad idea, because
the order of device save/restore is not fixed, and so this
cross-device access makes the save/restore non-deterministic.

We previously only flagged up this requirement in the
record-and-replay developer docs; repeat it in the main migration
documentation, where a developer trying to implement a post_load hook
is more likely to see it.

Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Reviewed-by: Michael Tokarev <mjt@tls.msk.ru>
Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
This commit is contained in:
Peter Maydell 2024-10-03 15:34:01 +01:00 committed by Michael Tokarev
parent db17daf8c4
commit e300f4c11d
2 changed files with 9 additions and 0 deletions

View File

@ -465,6 +465,12 @@ Examples of such API functions are:
- portio_list_set_address() - portio_list_set_address()
- portio_list_set_enabled() - portio_list_set_enabled()
Since the order of device save/restore is not defined, you must
avoid accessing or changing any other device's state in one of these
callbacks. (For instance, don't do anything that calls ``update_irq()``
in a ``post_load`` hook.) Otherwise, restore will not be deterministic,
and this will break execution record/replay.
Iterative device migration Iterative device migration
-------------------------- --------------------------

View File

@ -202,6 +202,9 @@ into the log.
Saving/restoring the VM state Saving/restoring the VM state
----------------------------- -----------------------------
Record/replay relies on VM state save and restore being complete and
deterministic.
All fields in the device state structure (including virtual timers) All fields in the device state structure (including virtual timers)
should be restored by loadvm to the same values they had before savevm. should be restored by loadvm to the same values they had before savevm.