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

[David Hildenbrand]

On 08.08.24 19:30, Peter Maydell wrote:
> On Thu, 8 Aug 2024 at 17:29, David Hildenbrand <david@redhat.com> wrote:
> > On 08.08.24 18:17, Peter Maydell wrote:
> > > 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).
> >
> > 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 :-))

:)

The main difference to ordinary RAM is that (virtio-mem) device memory 
is always detected by a guest OS driver, it's never part of the 
bios/firmware-provided memory map. And not all OSes support virtio-mem.

So one reason we added that handling in the beginning was if you would 
reboot from OS X to Y, whereby X suppors virtio-mem (and we hotplugged 
memory) and Y does not, then you would not leave that 
unusable-but-memory-consuming memory around for Y (possibly leaving 
customers paying for dynamic memory capacities angry).

Another reason was to force the fresh OS to effectively defragment 
hotplugged device memory (so we have less mixture of plugged and 
unplugged memory blocks that any previous OS might have left behind 
after unplugging memory).

Yet another reason was that one could have pending unplug requests 
(e.g., unplug 1 GiB, but only part of that request was fulfilled by the 
old OS), and this way we can easily enforce that once we get the chance to.

So to summarize, the idea was to "start from scratch" in all cases where 
it is safe. For wakeup, it apparently wasn't safe :)

--
Cheers,

David / dhildenb