diff options
author | Peter Maydell <peter.maydell@linaro.org> | 2024-04-12 17:08:09 +0100 |
---|---|---|
committer | Peter Maydell <peter.maydell@linaro.org> | 2024-04-25 10:21:59 +0100 |
commit | 631f46d4ea7cb7ac0e529aacc1e7d832473f96c3 (patch) | |
tree | 9fb50b1412c0c4a12ec3d371b30d65c3556630b5 /docs | |
parent | 41d49ec190db9171d2ebb158fd4d5daad06ed8e1 (diff) |
reset: Add RESET_TYPE_SNAPSHOT_LOAD
Some devices and machines need to handle the reset before a vmsave
snapshot is loaded differently -- the main user is the handling of
RNG seed information, which does not want to put a new RNG seed into
a ROM blob when we are doing a snapshot load.
Currently this kind of reset handling is supported only for:
* TYPE_MACHINE reset methods, which take a ShutdownCause argument
* reset functions registered with qemu_register_reset_nosnapshotload
To allow a three-phase-reset device to also distinguish "snapshot
load" reset from the normal kind, add a new ResetType
RESET_TYPE_SNAPSHOT_LOAD. All our existing reset methods ignore
the reset type, so we don't need to update any device code.
Add the enum type, and make qemu_devices_reset() use the
right reset type for the ShutdownCause it is passed. This
allows us to get rid of the device_reset_reason global we
were using to implement qemu_register_reset_nosnapshotload().
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Reviewed-by: Luc Michel <luc.michel@amd.com>
Message-id: 20240412160809.1260625-7-peter.maydell@linaro.org
Diffstat (limited to 'docs')
-rw-r--r-- | docs/devel/reset.rst | 17 |
1 files changed, 14 insertions, 3 deletions
diff --git a/docs/devel/reset.rst b/docs/devel/reset.rst index 49baa1ea27..9746a4e8a0 100644 --- a/docs/devel/reset.rst +++ b/docs/devel/reset.rst @@ -27,9 +27,7 @@ instantly reset an object, without keeping it in reset state, just call ``resettable_reset()``. These functions take two parameters: a pointer to the object to reset and a reset type. -Several types of reset will be supported. For now only cold reset is defined; -others may be added later. The Resettable interface handles reset types with an -enum: +The Resettable interface handles reset types with an enum ``ResetType``: ``RESET_TYPE_COLD`` Cold reset is supported by every resettable object. In QEMU, it means we reset @@ -37,6 +35,19 @@ enum: from what is a real hardware cold reset. It differs from other resets (like warm or bus resets) which may keep certain parts untouched. +``RESET_TYPE_SNAPSHOT_LOAD`` + This is called for a reset which is being done to put the system into a + clean state prior to loading a snapshot. (This corresponds to a reset + with ``SHUTDOWN_CAUSE_SNAPSHOT_LOAD``.) Almost all devices should treat + this the same as ``RESET_TYPE_COLD``. The main exception is devices which + have some non-deterministic state they want to reinitialize to a different + value on each cold reset, such as RNG seed information, and which they + must not reinitialize on a snapshot-load reset. + +Devices which implement reset methods must treat any unknown ``ResetType`` +as equivalent to ``RESET_TYPE_COLD``; this will reduce the amount of +existing code we need to change if we add more types in future. + Calling ``resettable_reset()`` is equivalent to calling ``resettable_assert_reset()`` then ``resettable_release_reset()``. It is possible to interleave multiple calls to these three functions. There may |