RE: How can a userspace program tell if the system supports the ACPI S4 state (Suspend-to-Disk)?

[Dexuan Cui]

> From: James Morse <james.morse@xxxxxxx>
> Sent: Tuesday, February 9, 2021 10:15 AM
> To: Dexuan Cui <decui@xxxxxxxxxxxxx>
> Cc: Rafael J. Wysocki <rafael@xxxxxxxxxx>; linux-acpi@xxxxxxxxxxxxxxx;
> linux-kernel@xxxxxxxxxxxxxxx; linux-hyperv@xxxxxxxxxxxxxxx; Michael Kelley
> <mikelley@xxxxxxxxxxxxx>; Leandro Pereira <Leandro.Pereira@xxxxxxxxxxxxx>
> Subject: Re: How can a userspace program tell if the system supports the ACPI
> S4 state (Suspend-to-Disk)?
> 
> Hi Dexuan,
> 
> On 05/02/2021 19:36, Dexuan Cui wrote:
> >> From: Rafael J. Wysocki <rafael@xxxxxxxxxx>
> >> Sent: Friday, February 5, 2021 5:06 AM
> >> To: Dexuan Cui <decui@xxxxxxxxxxxxx>
> >> Cc: linux-acpi@xxxxxxxxxxxxxxx; linux-kernel@xxxxxxxxxxxxxxx;
> >> linux-hyperv@xxxxxxxxxxxxxxx; Michael Kelley <mikelley@xxxxxxxxxxxxx>
> >> Subject: Re: How can a userspace program tell if the system supports the
> ACPI
> >> S4 state (Suspend-to-Disk)?
> >>
> >> On Sat, Dec 12, 2020 at 2:22 AM Dexuan Cui <decui@xxxxxxxxxxxxx> wrote:
> >>>
> >>> Hi all,
> >>> It looks like Linux can hibernate even if the system does not support the
> ACPI
> >>> S4 state, as long as the system can shut down, so "cat /sys/power/state"
> >>> always contains "disk", unless we specify the kernel parameter
> "nohibernate"
> >>> or we use LOCKDOWN_HIBERNATION.
> 
> >>> In some scenarios IMO it can still be useful if the userspace is able to
> >>> detect if the ACPI S4 state is supported or not, e.g. when a Linux guest
> >>> runs on Hyper-V, Hyper-V uses the virtual ACPI S4 state as an indicator
> >>> of the proper support of the tool stack on the host, i.e. the guest is
> >>> discouraged from trying hibernation if the state is not supported.
> 
> What goes wrong? This sounds like a funny way of signalling hypervisor policy.

Hi James,
Sorry if I have caused any confusion. My above description only applies to
x86 Linux VM on Hyper-V.

For ARM64 Hyper-V, I suspect the mainline Linux kernel still can't work in a
Linux VM running on ARM64 Hyper-V, so AFAIK the VM hibernation hasn't
been tested: it may work or may not work. This is in our To-Do list.

Linux VM on Hyper-V needs to know if hibernation is supported/enabled
for the VM, mainly due to 2 reasons:

1. In the VM, the hv_balloon driver should disable the balloon up/down
operations if hibernation is enabled for the VM, otherwise bad things can
happen, e.g. the hv_balloon driver allocates some pages and gives the
pages to the hyperpvisor; now if the VM is allowed to hibernate, later
when the VM resumes back, the VM loses the pages for ever, because
Hyper-V doesn't save the info of the pages that were from the VM, so
Hyper-V thinks no pages need to be returned to the VM.

2. If hibernation is enabled for a VM, the VM has a Linux agent program
that automatically creates and sets up the swap file for hibernation. If
hibernation is not enabled for the VM, the agent should not try to create
and set up the swap file for hibernation.
 
> >>> I know we can check the S4 state by 'dmesg':
> >>>
> >>> # dmesg |grep ACPI: | grep support
> >>> [    3.034134] ACPI: (supports S0 S4 S5)
> >>>
> >>> But this method is unreliable because the kernel msg buffer can be filled
> >>> and overwritten. Is there any better method? If not, do you think if the
> >>> below patch is appropriate? Thanks!
> >>
> >> Sorry for the delay.
> >>
> >> If ACPI S4 is supported, /sys/power/disk will list "platform" as one
> >> of the options (and it will be the default one then).  Otherwise,
> >> "platform" is not present in /sys/power/disk, because ACPI is the only
> >> user of hibernation_ops.
> 
> > This works on x86. Thanks a lot!
> >
> > BTW, does this also work on ARM64?
> 
> Not today. The S4/S5 stuff is part of 'ACPI_SYSTEM_POWER_STATES_SUPPORT',
> which arm64
> doesn't enable as it has a firmware mechanism that covers this on both DT and
> ACPI
> systems. That code is what calls hibernation_set_ops() to enable ACPI's
> platform mode.

Thanks for the explanation!

> Regardless: hibernate works fine. What does your hypervisor do that causes
> problems?
> (I think all we expect from firmware is it doesn't randomise the placement of
> the ACPI
> tables as they aren't necessarily part of the hibernate image)
> 
> Thanks, 
> James

I have explained the problems above for Linux VM on ARM64 Hyper-V.

I suppose you mean hibernation works fine for ARM64 bare metal. 
For Linux VM on ARM64 Hyper-V, I suspect some Hyper-V specific states may
have to be saved and restored for hibernation. This is in our To-Do lsit.

Thanks,
Dexuan