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

[Peter Maydell]

On Thu, 8 Aug 2024 at 16:31, David Hildenbrand <david@redhat.com> wrote:
>
> On 08.08.24 17:28, Juraj Marcin wrote:
> > On Thu, Aug 8, 2024 at 2:18 PM Peter Maydell <peter.maydell@linaro.org> 
> > wrote:
> >>
> >> On Tue, 6 Aug 2024 at 17:08, Juraj Marcin <jmarcin@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. 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?

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.

thanks
-- PMM