[PATCH 4/4] um: allow PM with suspend-to-idle

[Anton Ivanov]

On 20/11/2020 21:33, Johannes Berg wrote:
> On Fri, 2020-11-20 at 22:29 +0100, Johannes Berg wrote:
>> From: Johannes Berg <johannes.berg at intel.com>
>>
>> In order to be able to experiment with suspend in UML,
>> add the minimal work to be able to suspend (s2idle) an
>> instance of UML, and be able to wake it back up from
>> that state with the USR1 signal sent to the main UML
>> process.
> 
> So what I said about rtcwake ... maybe that's an argument for removing
> the USR1 handling? I wasn't really too sure about it.
> 
> But on the other hand, typically real systems will have at least *some*
> kind of wakeup source that you can manually use and that's always
> enabled, perhaps the power button for example; the SIGUSR1 handling was
> meant to simulate such a thing.

This usually translates to the IRQ controller being powered on even if 
the rest of the machine is off and some lines being able to function 
even in power down state.

Not that difficult actually. Going to sleep should just turn off all 
relevant IRQs including de-registering fds. If you are not 
de-registering the fds, the fact that it is turned off in the controller 
will be of no use - it will be re-triggered.

Waking up should restore the state.

Once that is in place, you can emulate the full PM sleep/wake up cycle.

Emulating suspend to disk is more interesting. I actually looked at it 
many years ago and that looked nearly impossible to implement.

> 
> (Today, if you send SIGUSR1 to the main 'linux' process, it just dies,
> but I hope nobody relies on that ...?)
> 
> johannes
> 
> 
> _______________________________________________
> linux-um mailing list
> linux-um at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-um
> 


-- 
Anton R. Ivanov
https://www.kot-begemot.co.uk/