Hi Ben,
It's true that the hypervisor can save the guest state and restore it later without the help from the guest kernel.
However, to make the user space applications in the guest (like the network daemons) aware of the suspend/resume, we want the entire suspend to RAM process (begins with hypervisor asserting SLPBTN_STS [1] and ends with guest kernel asserting SLP_TYP0 [2]) to run into completion so that guest OS can be prepared for the issues caused by the suspend/resume (e.g. the time jump). The write to SLP_TYP0 also serves as an acknowledgement from the guest OS that the sleep request has been processed successfully by the guest, the hypervisor can then start the saving of the guest state.
Daemons like acpid and systemd seem to also need "mem" to be included in /sys/power/state in order to respond to SLPBTN_STS [1] and I think whether "mem" is in /sys/power/state is controlled by the CONFIG_SUSPEND.
Control: tag -1 moreinfo
On Wed, 2020-10-28 at 12:29 -0700, Wanli Li wrote:
> Hi, just wanted to know whether there's any update on this feature request?
Why would this be needed in a cloud deployment? Hypervisors should be
able to suspend and resume guests without specific support in the guest
kernel.
Ben.
--
Ben Hutchings
You can't have everything. Where would you put it?