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.
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!
diff --git a/kernel/power/main.c b/kernel/power/main.c
index 0aefd6f57e0a..931a1526ea69 100644
--- a/kernel/power/main.c
+++ b/kernel/power/main.c
@@ -9,6 +9,7 @@
#include <linux/export.h>
#include <linux/kobject.h>
#include <linux/string.h>
+#include <linux/acpi.h>
#include <linux/pm-trace.h>
#include <linux/workqueue.h>
#include <linux/debugfs.h>
@@ -600,8 +601,12 @@ static ssize_t state_show(struct kobject *kobj, struct kobj_attribute *attr,
s += sprintf(s,"%s ", pm_states[i]);
#endif
- if (hibernation_available())
- s += sprintf(s, "disk ");
+ if (hibernation_available()) {
+ if (acpi_sleep_state_supported(ACPI_STATE_S4))
+ s += sprintf(s, "disk+ ");
+ else
+ s += sprintf(s, "disk ");
+ }
if (s != buf)
/* convert the last space to a newline */
*(s-1) = '\n';
Thanks,
-- Dexuan
On Sat 2020-12-12 01:20:30, Dexuan Cui 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.
Umm. Does not sound like exactly strong reason to me.
If ACPI S4 is special to the hypervisor, perhaps that should be
reported to userspace...?
> 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!
> @@ -600,8 +601,12 @@ static ssize_t state_show(struct kobject *kobj, struct kobj_attribute *attr,
> s += sprintf(s,"%s ", pm_states[i]);
>
> #endif
> - if (hibernation_available())
> - s += sprintf(s, "disk ");
> + if (hibernation_available()) {
> + if (acpi_sleep_state_supported(ACPI_STATE_S4))
> + s += sprintf(s, "disk+ ");
> + else
> + s += sprintf(s, "disk ");
> + }
> if (s != buf)
Will this compile on all the systems?
Certainly needs documentation.
Plus if ACPI S4 is supported, kernel can support both normal
hibernation and ACPI S4... so perhaps it should list two entries? And
"disk+" sounds wrong, "acpidisk"?
...and that would bring next question. Usespace writes "disk" there
and uses different file to select between S4 and S5...
Pavel
--
http://www.livejournal.com/~pavelmachek
> From: Pavel Machek <[email protected]>
> Sent: Monday, December 21, 2020 11:08 AM
>
> On Sat 2020-12-12 01:20:30, Dexuan Cui 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.
>
> Umm. Does not sound like exactly strong reason to me.
Hi Pavel,
Thanks for the reply. I realized that it may be better for me to add the code
to Hyper-V specific driver: https://lkml.org/lkml/2020/12/22/719
Let's see how it goes that way. :-)
Thanks,
Dexuan
> From: Rafael J. Wysocki <[email protected]>
> Sent: Friday, February 5, 2021 5:06 AM
> To: Dexuan Cui <[email protected]>
> Cc: [email protected]; [email protected];
> [email protected]; Michael Kelley <[email protected]>
> 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 <[email protected]> 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.
> >
> > 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.
>
> HTH
This works on x86. Thanks a lot!
BTW, does this also work on ARM64?
Thanks,
-- Dexuan
On Sat, Dec 12, 2020 at 2:22 AM Dexuan Cui <[email protected]> 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.
>
> 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.
HTH
Hi Dexuan,
On 05/02/2021 19:36, Dexuan Cui wrote:
>> From: Rafael J. Wysocki <[email protected]>
>> Sent: Friday, February 5, 2021 5:06 AM
>> To: Dexuan Cui <[email protected]>
>> Cc: [email protected]; [email protected];
>> [email protected]; Michael Kelley <[email protected]>
>> 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 <[email protected]> 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.
>>> 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.
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
> From: James Morse <[email protected]>
> Sent: Tuesday, February 9, 2021 10:15 AM
> To: Dexuan Cui <[email protected]>
> Cc: Rafael J. Wysocki <[email protected]>; [email protected];
> [email protected]; [email protected]; Michael Kelley
> <[email protected]>; Leandro Pereira <[email protected]>
> 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 <[email protected]>
> >> Sent: Friday, February 5, 2021 5:06 AM
> >> To: Dexuan Cui <[email protected]>
> >> Cc: [email protected]; [email protected];
> >> [email protected]; Michael Kelley <[email protected]>
> >> 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 <[email protected]> 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