Re: [PATCH 2/4] reset: Add RESET_TYPE_WAKEUP

[Peter Maydell]

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.

By the way, I assume this patchseries is 9.2 material,
not trying to fix a bug for this release ?

thanks
-- PMM