On 08.08.24 17:56, Peter Maydell wrote:
On Thu, 8 Aug 2024 at 16:31, David Hildenbrand <da...@redhat.com> wrote:
On 08.08.24 17:28, Juraj Marcin wrote:
On Thu, Aug 8, 2024 at 2:18 PM Peter Maydell <peter.mayd...@linaro.org> wrote:
On Tue, 6 Aug 2024 at 17:08, Juraj Marcin <jmar...@redhat.com> wrote:
+``RESET_TYPE_WAKEUP``
+ This type is used when the machine is woken up from a suspended state (deep
+ sleep, suspend-to-ram). Devices that must not be reset to their initial state
+ after wake-up (for example virtio-mem) can use this state to differentiate
+ cold start from wake-up can use this state to differentiate cold start from
+ wake-up.
I feel like this needs more clarity about what this is, since
as a reset type it's a general behaviour, not a machine
specific one. What exactly is "wakeup" and when does it happen?
How does it differ from what you might call a "warm" reset,
where the user pressed the front-panel reset button?
Why is virtio-mem in particular interesting here?
Thank you for the feedback!
I have rewritten the paragraph:
This type is called for a reset when the system is being woken up from
a suspended state using the ``qemu_system_wakeup()`` function. If the
machine type needs to reset in its ``MachineClass::wakeup()`` method,
this reset type should be used so that devices can differentiate
system wake-up from other reset types. For example, a virtio-mem
device must not unplug its memory during wake-up, as that would clear
the guest RAM.
Is it clearer? Thank you!
Conceptually, if we want to avoid the "WAKEUP" terminology here, maybe
we should consider talking about a WARM reset -- in contrast to a COLD one?
During a WARM reset, memory content is supposed to stay untouched, which
is what we effectively want to achieve with virtio-mem.
Right, I guess that's my question -- is "WAKEUP" ever any
different from "WARM" reset? I think the latter is a more
common general concept.
On the other hand it looks like we already have the
concept in the runstate state machine of
RUN_STATE_SUSPENDED versus RUN_STATE_RUNNING, and so if we
define "WAKEUP" as "goes from SUSPENDED to RUNNING" that's
quite a clearly defined condition.
Right.
Whereas WARM reset would
be a much wider range of things and ought to include for
instance "guest triggers a reset by writing to port 92"
and all the other SHUTDOWN_CAUSE_GUEST_RESET cases.
(Side note: do we document all these runstates and transitions
anywhere?)
For virtio-mem, on a guest-triggered reset, should it
(a) definitely not unplug all the hotplugged memory
(b) definitely unplug all the hotplugged memory
(c) we don't care?
During ordinary system resets (COLD) where RAM content is not guaranteed
to survive:
Effectively (b)
During special kexec-style resets (e.g., on s390x there is a difference)
where RAM content must survive:
Effectively (a)
On implementing architectures (x86, arm64), kexec-style resets are
really like warm resets. For example, when we trigger kexec->kdump we
must not suddenly lose the RAM content.
In that sense, at least virtio-mem wants to treat WARM and WAKEUP resets
alike. But I agree that simply because virtio-mem want sot treat them
alike doesn't mean that we should represent in QEMU using a single reset
type.
WARM reboots like s390x supports are rather stuff for the future (once
s390x actually supports virtio-mem and could end up triggering it).
If (a) then that seems to push towards calling all these
cases of a "warm" reset; if (b) then that would be a
reason to make "warm" and "wakeup" different.
Likely different then.
--
Cheers,
David / dhildenb
