Received: by 2002:a05:6a10:f347:0:0:0:0 with SMTP id d7csp4389122pxu; Mon, 21 Dec 2020 11:09:30 -0800 (PST) X-Google-Smtp-Source: ABdhPJxuFYNFrxvbFXpVmNBEb2+FLoSuZtDFsb5UH8V7azXmhXT70z2c5PRpm4OxABNRXYr/4Nb8 X-Received: by 2002:a17:907:435c:: with SMTP id oc20mr17052892ejb.286.1608577770649; Mon, 21 Dec 2020 11:09:30 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1608577770; cv=none; d=google.com; s=arc-20160816; b=lGTbBzUe0c9EYKyocmq2OrMAfh7dPf0w9hSE7egMMoARzGIU4BfnqD7J0O2xldCEZW ehaSBkSVCgp1pHnKO4vB9Y3fLfTG7RbiSlbpbRz1E2W0Oy2BR9cYXLylY0n1VVetaHLr oOYl4MMYpeIN7QQtZCKYYtZMQLkrI17uIGD/LOlQPPb60iugAVJ3UkEqGmu0sIUFgrQV 6LDxeN1kcxb4y6wm3Rw2axqIAzHYFSFPTMykzldKlXEjp0mkgaurtJYwvAs3G67O4Tlk Fp+0COAJLZNpBxMeRoq4R/yAbAlCwKevdvcISeUEUN/6C+Wra7GCcfgt+7ZTBFBJFZgA uiuw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:user-agent:in-reply-to:content-disposition :mime-version:references:message-id:subject:cc:to:from:date; bh=U3yhFGNRY2/Pql9feYVFZBOHNgGT1lvC0ZwEowzj75c=; b=nczlsrVZdUBbUxU2Vf8o3T65Pu5SxwDGzUJMdkGahjGFeAbE/WrtB27KnFZlxGwioH FqFT7ip8KiJslly6QxegY5ooHApYJMDmltE6tLrrhT1vyZosBa1r6nYj2Slr2xItXz/Z qOadalwiJNWi8O4+Bh+D8yB3BZEDZgnv+M9ZN1VC7dYAjCCOZPLh0onUsN5p77gF/b81 g0ZMSKxBekRrPva1Ugg0vmvLweGEGYHy8SnBFAGB80LZHoUkyP0PGMDQKaUI9vvqWFE1 M07NiJMBuMzH6KrRsQteHVH6+I3cl7/IZFHID1Z8SB0MqlBk2KyY+ejFgw9M/2jYaUTw bCJA== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id d24si10895598edu.93.2020.12.21.11.09.08; Mon, 21 Dec 2020 11:09:30 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726470AbgLUTIP (ORCPT + 99 others); Mon, 21 Dec 2020 14:08:15 -0500 Received: from jabberwock.ucw.cz ([46.255.230.98]:57986 "EHLO jabberwock.ucw.cz" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726345AbgLUTIO (ORCPT ); Mon, 21 Dec 2020 14:08:14 -0500 Received: by jabberwock.ucw.cz (Postfix, from userid 1017) id 245031C0B7C; Mon, 21 Dec 2020 20:07:33 +0100 (CET) Date: Mon, 21 Dec 2020 20:07:32 +0100 From: Pavel Machek To: Dexuan Cui Cc: "linux-acpi@vger.kernel.org" , "linux-kernel@vger.kernel.org" , "linux-hyperv@vger.kernel.org" , Michael Kelley Subject: Re: How can a userspace program tell if the system supports the ACPI S4 state (Suspend-to-Disk)? Message-ID: <20201221190731.GA19905@amd> References: MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="BOKacYhQ+x31HxR3" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org --BOKacYhQ+x31HxR3 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable 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 "nohiberna= te" > or we use LOCKDOWN_HIBERNATION. >=20 > 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= =20 > Hyper-V, Hyper-V uses the virtual ACPI S4 state as an indicator of the pr= oper > support of the tool stack on the host, i.e. the guest is discouraged from= =20 > 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': >=20 > # dmesg |grep ACPI: | grep support > [ 3.034134] ACPI: (supports S0 S4 S5) >=20 > 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, stru= ct kobj_attribute *attr, > s +=3D sprintf(s,"%s ", pm_states[i]); >=20 > #endif > - if (hibernation_available()) > - s +=3D sprintf(s, "disk "); > + if (hibernation_available()) { > + if (acpi_sleep_state_supported(ACPI_STATE_S4)) > + s +=3D sprintf(s, "disk+ "); > + else > + s +=3D sprintf(s, "disk "); > + } > if (s !=3D 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"? =2E..and that would bring next question. Usespace writes "disk" there and uses different file to select between S4 and S5... Pavel --=20 http://www.livejournal.com/~pavelmachek --BOKacYhQ+x31HxR3 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iEYEARECAAYFAl/g8nMACgkQMOfwapXb+vLkgwCeMW2fXbRDW6Sr2dCIQGMICYaX sBsAoJgURNDoL/yTSiY5EuI7q+BdCwvx =HAYT -----END PGP SIGNATURE----- --BOKacYhQ+x31HxR3--