Messages in this thread | | | Subject | Re: [2.6.21.1] resume doesn't run suspended kernel? | From | Nigel Cunningham <> | Date | Tue, 29 May 2007 08:48:02 +1000 |
| |
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 [unhandled content-type:application/pgp-signature] | |