[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <1180392482.4149.15.camel@nigel.suspend2.net>
Date: Tue, 29 May 2007 08:48:02 +1000
From: Nigel Cunningham <nigel@...el.suspend2.net>
To: "Rafael J. Wysocki" <rjw@...k.pl>
Cc: Pavel Machek <pavel@....cz>, Bill Davidsen <davidsen@....com>,
Linux Kernel M/L <linux-kernel@...r.kernel.org>
Subject: Re: [2.6.21.1] resume doesn't run suspended kernel?
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
Download attachment "signature.asc" of type "application/pgp-signature" (190 bytes)
Powered by blists - more mailing lists