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). > 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
