mirrors/qemu
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

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

Browse Source 
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
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

6
docs/devel/migration/main.rst
View File

@ -465,6 +465,12 @@ Examples of such API functions are:
- portio_list_set_address()
- 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
--------------------------

3
docs/devel/replay.rst
View File

@ -202,6 +202,9 @@ into the log.
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)
should be restored by loadvm to the same values they had before savevm.