linux-hyperv.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: James Morse <james.morse@arm.com>
To: Dexuan Cui <decui@microsoft.com>
Cc: "Rafael J. Wysocki" <rafael@kernel.org>,
	"linux-acpi@vger.kernel.org" <linux-acpi@vger.kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"linux-hyperv@vger.kernel.org" <linux-hyperv@vger.kernel.org>,
	Michael Kelley <mikelley@microsoft.com>,
	Leandro Pereira <Leandro.Pereira@microsoft.com>
Subject: Re: How can a userspace program tell if the system supports the ACPI S4 state (Suspend-to-Disk)?
Date: Tue, 9 Feb 2021 18:15:17 +0000	[thread overview]
Message-ID: <204fa040-115e-552a-5fc1-5520f10bc402@arm.com> (raw)
In-Reply-To: <MW2PR2101MB1787B5253CAA640F8B7D2860BFB29@MW2PR2101MB1787.namprd21.prod.outlook.com>

Hi Dexuan,

On 05/02/2021 19:36, Dexuan Cui wrote:
>> From: Rafael J. Wysocki <rafael@kernel.org>
>> Sent: Friday, February 5, 2021 5:06 AM
>> To: Dexuan Cui <decui@microsoft.com>
>> Cc: linux-acpi@vger.kernel.org; linux-kernel@vger.kernel.org;
>> linux-hyperv@vger.kernel.org; Michael Kelley <mikelley@microsoft.com>
>> 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@microsoft.com> 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

  reply	other threads:[~2021-02-09 18:20 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-12-12  1:20 How can a userspace program tell if the system supports the ACPI S4 state (Suspend-to-Disk)? Dexuan Cui
2020-12-21 19:07 ` Pavel Machek
2020-12-23 21:04   ` Dexuan Cui
2021-02-05 13:05 ` Rafael J. Wysocki
2021-02-05 19:36   ` Dexuan Cui
2021-02-09 18:15     ` James Morse [this message]
2021-02-10  7:00       ` Dexuan Cui

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=204fa040-115e-552a-5fc1-5520f10bc402@arm.com \
    --to=james.morse@arm.com \
    --cc=Leandro.Pereira@microsoft.com \
    --cc=decui@microsoft.com \
    --cc=linux-acpi@vger.kernel.org \
    --cc=linux-hyperv@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mikelley@microsoft.com \
    --cc=rafael@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).