On Thu, 8 Aug 2024 at 17:04, David Hildenbrand <david@redhat.com> wrote:
On 08.08.24 17:56, Peter Maydell wrote:
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:
"COLD" isn't an "ordinary system reset", though -- COLD
reset is more like "I powered the computer off and then
turned it on again". A "WARM" reset is like "I pressed
the front panel reset button, or the watchdog device
fired and reset the system". We don't currently really
model front-panel or watchdog reset properly, we assume
that it's close enough to have it be the same as
power-off-and-on reset (and there are some kludges in
various places where it's not quite right).
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.
(There's an awkward conflict here with our rom blob
system, which currently does a "copy any guest images
back into RAM" on reset. Should we do that on warm
reset? For some usecases you want those original
images back again, but for "guest did a kexec" you
almost certainly don't...)
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.
On the other hand, if virtio-mem does want to treat them
the same we could start with only implementing WARM and
not add WAKEUP until we have a use-case for it.