On Tue, Mar 12, 2024 at 01:51:29PM +0000, David Woodhouse wrote:
> From: David Woodhouse <[email protected]>
>
> The PSCI v1.3 specification (alpha) 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 handle that state appropriately on subsequent launches.
>
> Since commit 60c0d45a7f7a ("efi/arm64: use UEFI for system reset and
> poweroff") the EFI shutdown method is deliberately preferred over PSCI
> or other methods. So register a SYS_OFF_MODE_POWER_OFF handler which
> *only* handles the hibernation, leaving the original PSCI SYSTEM_OFF as
> a last resort via the legacy pm_power_off function pointer.
>
> The hibernation code already exports a system_entering_hibernation()
> function which is be used by the higher-priority handler to check for
> hibernation. That existing function just returns the value of a static
> boolean variable from hibernate.c, which was previously only set in the
> hibernation_platform_enter() code path. Set the same flag in the simpler
> code path around the call to kernel_power_off() too.
>
> An alternative way to hook SYSTEM_OFF2 into the hibernation code would
> be to register a platform_hibernation_ops structure with an ->enter()
> method which makes the new SYSTEM_OFF2 call. But that would have the
> unwanted side-effect of making hibernation take a completely different
> code path in hibernation_platform_enter(), invoking a lot of special dpm
> callbacks.
>
> Another option might be to add a new SYS_OFF_MODE_HIBERNATE mode, with
> fallback to SYS_OFF_MODE_POWER_OFF. Or to use the sys_off_data to
> indicate whether the power off is for hibernation.
>
> But this version works and is relatively simple.
>
> Signed-off-by: David Woodhouse <[email protected]>
> ---
> drivers/firmware/psci/psci.c | 35 +++++++++++++++++++++++++++++++++++
> kernel/power/hibernate.c | 5 ++++-
> 2 files changed, 39 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/firmware/psci/psci.c b/drivers/firmware/psci/psci.c
> index d9629ff87861..69d2f6969438 100644
> --- a/drivers/firmware/psci/psci.c
> +++ b/drivers/firmware/psci/psci.c
> @@ -78,6 +78,7 @@ struct psci_0_1_function_ids get_psci_0_1_function_ids(void)
>
> static u32 psci_cpu_suspend_feature;
> static bool psci_system_reset2_supported;
> +static bool psci_system_off2_supported;
>
> static inline bool psci_has_ext_power_state(void)
> {
> @@ -333,6 +334,28 @@ static void psci_sys_poweroff(void)
> invoke_psci_fn(PSCI_0_2_FN_SYSTEM_OFF, 0, 0, 0);
> }
>
> +#ifdef CONFIG_HIBERNATION
> +static int psci_sys_hibernate(struct sys_off_data *data)
> +{
> + if (system_entering_hibernation())
> + invoke_psci_fn(PSCI_FN_NATIVE(1_3, SYSTEM_OFF2),
> + PSCI_1_3_HIBERNATE_TYPE_OFF, 0, 0);
> + return NOTIFY_DONE;
> +}
> +
> +static int __init psci_hibernate_init(void)
> +{
> + if (psci_system_off2_supported) {
> + /* Higher priority than EFI shutdown, but only for hibernate */
> + register_sys_off_handler(SYS_OFF_MODE_POWER_OFF,
> + SYS_OFF_PRIO_FIRMWARE + 2,
> + psci_sys_hibernate, NULL);
> + }
> + return 0;
> +}
> +subsys_initcall(psci_hibernate_init);
Looked briefly at register_sys_off_handler and it should be OK to call
it from psci_init_system_off2() below. Any particular reason for having
separate initcall to do this ? We can even eliminate the need for
psci_init_system_off2 if it can be called from there. What am I missing ?
--
Regards,
Sudeep
On Tue, 2024-03-12 at 15:57 +0000, Sudeep Holla wrote:
> Looked briefly at register_sys_off_handler and it should be OK to call
> it from psci_init_system_off2() below. Any particular reason for having
> separate initcall to do this ? We can even eliminate the need for
> psci_init_system_off2 if it can be called from there. What am I missing ?
My first attempt did that. I don't think we can kmalloc that early:
[ 0.000000] psci: SMC Calling Convention v1.1
[ 0.000000] Unable to handle kernel read from unreadable memory at virtual address 0000000000000018
[ 0.000000] Mem abort info:
[ 0.000000] ESR = 0x0000000096000004
[ 0.000000] EC = 0x25: DABT (current EL), IL = 32 bits
[ 0.000000] SET = 0, FnV = 0
[ 0.000000] EA = 0, S1PTW = 0
[ 0.000000] FSC = 0x04: level 0 translation fault
[ 0.000000] Data abort info:
[ 0.000000] ISV = 0, ISS = 0x00000004, ISS2 = 0x00000000
[ 0.000000] CM = 0, WnR = 0, TnD = 0, TagAccess = 0
[ 0.000000] GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0
[ 0.000000] [0000000000000018] user address but active_mm is swapper
[ 0.000000] Internal error: Oops: 0000000096000004 [#1] SMP
[ 0.000000] Modules linked in:
[ 0.000000] CPU: 0 PID: 0 Comm: swapper Not tainted 6.8.0-rc3+ #30
[ 0.000000] pstate: 804000c5 (Nzcv daIF +PAN -UAO -TCO -DIT -SSBS BTYPE=--)
[ 0.000000] pc : kmalloc_trace+0x138/0x340
[ 0.000000] lr : register_sys_off_handler+0x60/0x258
[ 0.000000] sp : ffff8000827d3d10
[ 0.000000] x29: ffff8000827d3d20 x28: 000000005cd7e0ac x27: 0000000000001f3f
[ 0.000000] x26: 0000000000000000 x25: ffff8000802bd890 x24: ffff8000802bd890
[ 0.000000] x23: 0000000000000040 x22: 0000000000000dc0 x21: 0000000000000001
[ 0.000000] x20: 0000000000000000 x19: 0000000000000000 x18: 0000000000000006
[ 0.000000] x17: 000000000036fd40 x16: 000000005ec902c0 x15: ffff8000827d37c0
[ 0.000000] x14: 0000000000000000 x13: 312e3176206e6f69 x12: 746e65766e6f4320
[ 0.000000] x11: 00000000ffffdfff x10: ffff8000828cebe0 x9 : ffff80008281ea10
[ 0.000000] x8 : ffff8000827d3d78 x7 : 0000000000000000 x6 : 0000000000000000
[ 0.000000] x5 : 0000000000000000 x4 : ffff8000827e0000 x3 : ffff8000827f41c0
[ 0.000000] x2 : 0000000000000040 x1 : 0000000000000dc0 x0 : 0000000000000000
[ 0.000000] Call trace:
[ 0.000000] kmalloc_trace+0x138/0x340
[ 0.000000] register_sys_off_handler+0x60/0x258
[ 0.000000] psci_probe+0x2cc/0x350
[ 0.000000] psci_acpi_init+0x50/0x88
[ 0.000000] setup_arch+0x194/0x278
[ 0.000000] start_kernel+0x7c/0x410
[ 0.000000] __primary_switched+0xb8/0xc8
[ 0.000000] Code: b5000f7a f94003f4 aa1803fe d50320ff (b9401a64)
[ 0.000000] ---[ end trace 0000000000000000 ]---
[ 0.000000] Kernel panic - not syncing: Attempted to kill the idle task!
[ 0.000000] ---[ end Kernel panic - not syncing: Attempted to kill the idle task! ]---
On Tue, Mar 12, 2024 at 04:36:05PM +0000, David Woodhouse wrote:
> On Tue, 2024-03-12 at 15:57 +0000, Sudeep Holla wrote:
> > Looked briefly at register_sys_off_handler and it should be OK to call
> > it from psci_init_system_off2() below. Any particular reason for having
> > separate initcall to do this ? We can even eliminate the need for
> > psci_init_system_off2 if it can be called from there. What am I missing ?
>
> My first attempt did that. I don't think we can kmalloc that early:
>
That was was initial guess. But a quick hack on my setup and running it on
the FVP model didn't complain. I think either I messed up or something else
wrong, I must check on some h/w. Anyways sorry for the noise and thanks for
the response.
--
Regards,
Sudeep
On Wed, Mar 13, 2024 at 03:34:44PM +0000, Sudeep Holla wrote:
> On Tue, Mar 12, 2024 at 04:36:05PM +0000, David Woodhouse wrote:
> > On Tue, 2024-03-12 at 15:57 +0000, Sudeep Holla wrote:
> > > Looked briefly at register_sys_off_handler and it should be OK to call
> > > it from psci_init_system_off2() below. Any particular reason for having
> > > separate initcall to do this ? We can even eliminate the need for
> > > psci_init_system_off2 if it can be called from there. What am I missing ?
> >
> > My first attempt did that. I don't think we can kmalloc that early:
> >
>
> That was was initial guess. But a quick hack on my setup and running it on
> the FVP model didn't complain. I think either I messed up or something else
> wrong, I must check on some h/w. Anyways sorry for the noise and thanks for
> the response.
>
OK, it was indeed giving -ENOMEM which in my hack didn't get propogated
properly ????. I assume you have some configs that is resulting in the
crash instead of -ENOMEM as I see in my setup(FVP as well as hardware).
Sorry for the noise.
--
Regards,
Sudeep
On 14 March 2024 12:09:11 CET, Sudeep Holla <[email protected]> wrote:
>On Wed, Mar 13, 2024 at 03:34:44PM +0000, Sudeep Holla wrote:
>> On Tue, Mar 12, 2024 at 04:36:05PM +0000, David Woodhouse wrote:
>> > On Tue, 2024-03-12 at 15:57 +0000, Sudeep Holla wrote:
>> > > Looked briefly at register_sys_off_handler and it should be OK to call
>> > > it from psci_init_system_off2() below. Any particular reason for having
>> > > separate initcall to do this ? We can even eliminate the need for
>> > > psci_init_system_off2 if it can be called from there. What am I missing ?
>> >
>> > My first attempt did that. I don't think we can kmalloc that early:
>> >
>>
>> That was was initial guess. But a quick hack on my setup and running it on
>> the FVP model didn't complain. I think either I messed up or something else
>> wrong, I must check on some h/w. Anyways sorry for the noise and thanks for
>> the response.
>>
>
>OK, it was indeed giving -ENOMEM which in my hack didn't get propogated
>properly ????. I assume you have some configs that is resulting in the
>crash instead of -ENOMEM as I see in my setup(FVP as well as hardware).
>
>Sorry for the noise.
Fairly stock Fedora config, with a few tweaks.
http://david.woodhou.se/arm-hibernate-config
I note kmalloc_trace() is in the backtrace.