On Thu, 8 Aug 2024 at 17:29, David Hildenbrand <da...@redhat.com> wrote:
>
> On 08.08.24 18:17, Peter Maydell wrote:
> > On Thu, 8 Aug 2024 at 17:04, David Hildenbrand <da...@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).
>
> Agreed, there are many flavors of resets, even different flavors of warm
> ones I'm afraid.
>
> To summarize, if a VM does an ordinary reset ("shutdown -r") we want to
> unplug all hotplugged memory. Same with most external resets we
> currently implement. In all other caes, we likely want to keep the
> memory hotplugged and RAM content alive.

OK, if we want 'shutdown -r' to unplug hotplugged memory
then that sounds like we do want a WAKEUP reset type.
(Though I'm surprised that we want that -- my expectation
would have been that the hotplugged memory should stay,
because if you do real hardware hotplug of RAM then it
doesn't all pop back out of the sockets when you press
the reset button on the front panel :-))

thanks
-- PMM

Reply via email to