Re: [2.6.21.1] resume doesn't run suspended kernel?

[Nigel Cunningham <nigel@nigel.suspend2.net>]

[-- Attachment #1: Type: text/plain, Size: 1442 bytes --]

Hi.

On Mon, 2007-05-28 at 19:57 +0200, Rafael J. Wysocki wrote:
> On Monday, 28 May 2007 15:26, Pavel Machek wrote:
> > Hi!
> > 
> > > >That's clear, I'll have to use xen or kvm or similar which restores 
> > > >the system as suspended. Thanks for the clarification of the limitations.
> > > >
> > > Sorry, I wrote that late at night and quickly. I should have said 
> > > "design decision" rather than "limitation," For systems which don't do 
> > > multiple kernels it's not an issue.
> > > 
> > > I certainly would not have made the same decision, but I didn't write 
> > > the code. It seems more robust to save everything than to try to 
> > > identify what has and hasn't changed in a modular kernel.
> > 
> > We rely on atomic copy routine not moving inside the kernel. Yes, it
> > would be possible to copy it to "known good" address and gain ability
> > to resume different kernels. Actually it should not be _that_ hard.
> 
> Yup.  Don't we do something like this for the (ACPI-based) suspend to RAM
> already?

Yeah, I was thinking about this overnight too. It should be doable. In
addition to what we already do, I think you'd want:

- to copy the assembly to do the copying to a safe page;
- to put the location of the cpu state that was saved in the image
header so that it can be used after the data is copied back;
- to copy the nosave data to a 'safe' page.

What else?

Regards,

Nigel

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]