Re: [RFC V2 PATCH 11/11] arm/virt: enable sleep support

[Miguel Luis <miguel.luis@oracle.com>]

Hi Peter,

> On 8 Oct 2024, at 11:53, Peter Maydell <peter.maydell@linaro.org> wrote:
> 
> On Fri, 27 Sept 2024 at 19:40, Annie Li <annie.li@oracle.com> wrote:
>> 
>> From: Miguel Luis <miguel.luis@oracle.com>
>> 
>> For reference: qmp_system_sleep relies on wakeup support delegated
>> by qemu_wakeup_suspend_enabled() hence the need for calling
>> qemu_register_wakeup_support(). With this, we should be able to
>> issue QMP system_sleep command now.
>> 
>> Signed-off-by: Miguel Luis <miguel.luis@oracle.com>
>> ---
>> hw/arm/virt.c | 1 +
>> 1 file changed, 1 insertion(+)
>> 
>> diff --git a/hw/arm/virt.c b/hw/arm/virt.c
>> index 6be80f042f..370ee4fe7f 100644
>> --- a/hw/arm/virt.c
>> +++ b/hw/arm/virt.c
>> @@ -2403,6 +2403,7 @@ static void machvirt_init(MachineState *machine)
>> 
>>      /* connect sleep request */
>>      vms->sleep_notifier.notify = virt_sleep_req;
>> +     qemu_register_wakeup_support();
> 
> On i386 the machine has a MachineClass::wakeup method
> (pc_machine_wakeup) that does things on wakeup.
> 
> On ppc/spapr there is this comment before the call
> to qemu_register_wakeup_support():
>    /*
>     * Nothing needs to be done to resume a suspended guest because
>     * suspending does not change the machine state, so no need for
>     * a ->wakeup method.
>     */
> 
> I think that for Arm we need to determine whether the virt
> board is like i386/pc (need to do something on wakeup) or
> like ppc/spapr (don't need to do anything on wakeup). If the
> former, we obviously would need to implement the
> MachineClass::wakeup method; if the latter, then we
> should have a comment explaining why there doesn't need
> to be any action taken on resume and therefore the machine
> has no wakeup method.
> 

I believe it will be needed to reset the cpus and restore context afterwards but
before that I’m yet still to find a reliable wakeup source for the
experiments.

So far I’ve tried the rtc-efi wakeup source but it seems not supporting time in
the future in wakealarm so there’s still pending research on this. 

Direction hints for acceptable ways forward are always welcome, of course.
Many thanks for that.

Miguel

> thanks
> -- PMM