The upcoming PSCI v1.3 specification adds support for a SYSTEM_OFF2 function which is analogous to ACPI S4 state. This will allow hosting environments to determine that a guest is hibernated rather than just powered off, and ensure that they preserve the virtual environment appropriately to allow the guest to resume safely (or bump the hardware_signature in the FACS to trigger a clean reboot instead). This adds support for it to KVM, and to the guest hibernate code. Strictly, we should perhaps also allow the guest to detect PSCI v1.3, but when v1.1 was added in commit 512865d83fd9 it was done unconditionally, which seems wrong. Shouldn't we have a way for userspace to control what gets exposed, rather than silently changing the guest behaviour with newer host kernels? Should I add a KVM_CAP_ARM_PSCI_VERSION? For the guest side, this adds a new SYS_OFF_MODE_POWER_OFF with higher priority than the EFI one, but which *only* triggers when there's a hibernation in progress. That seemed like the simplest option, but see the commit message for alternative possilities. I told Rafael I'd post a straw man for bikeshedding, and here it is. Documentation/virt/kvm/api.rst | 11 +++++++++++ arch/arm64/include/asm/kvm_host.h | 2 ++ arch/arm64/include/uapi/asm/kvm.h | 6 ++++++ arch/arm64/kvm/arm.c | 5 +++++ arch/arm64/kvm/hyp/nvhe/psci-relay.c | 2 ++ arch/arm64/kvm/psci.c | 37 ++++++++++++++++++++++++++++++++++++ drivers/firmware/psci/psci.c | 35 ++++++++++++++++++++++++++++++++++ include/uapi/linux/kvm.h | 1 + include/uapi/linux/psci.h | 5 +++++ kernel/power/hibernate.c | 5 ++++- 10 files changed, 108 insertions(+), 1 deletion(-)
