On 08.08.24 19:30, Peter Maydell wrote:
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 :-))
:)
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
