On Mon, 16 Jul 2007, Rafael J. Wysocki wrote:
On Sunday, 15 July 2007 21:23, [email protected] wrote:
On Sun, 15 Jul 2007, Rafael J. Wysocki wrote:
I think this is far more complicated then it needs to be.
it sounds like it should be possible to do the following
1. figure out what pages should be backed up (creating a data structure to
hold them)
That should be done after step 2, because the memory contents can change
in this step.
no, this needs to be done by the main kernel, becouse only it knows how to
find this info. the kernel that you kexec into could be very different
(including different versions) and the ways to identify this data is not
part of any existing API
If the memory contents changes in step 2, then the information collected by
the main kernel will be inaccurate.
why would the memory use change when the new kernel is run? is it becouse
of whatever it does to the devices for the hand-off?
Yes, I think so, although I'm not sure, because I don't know what happens to
devices during a "normal" kexec.
is this a matter of running some test to find out, or is this a question
for the kexec implemantors?
during the wakeup stage, I thought you said that al that was needed was to
feed the suspend image to /dev/suspend and the kernel in the suspend image
would re-probe, or otherwise re-initialize all the devices it needs. am I
misunderstanding this?
Perhaps. Currently, the hibernated kernel will run device_resume() after
the restore, which is not exactly compatible with what kexec does.
but kexec isn't needed during the restore process, is it?
Generally, it's not needed. _However_, the current handling of devices is
such that:
(a) hibernated kernel uses device_suspend() to put them into low power states
and creates the image
(b) hibernated kernel uses device_resume() to get devices back to work and
saves the image
(c) during the restore the boot kernel loads the image and uses
device_suspend() to prepare devices for the "old" kernel
(d) hibernated kernel gets control and uses device_resume() to get devices back
to work.
Now, if you use kexec instead of (a) and (b), then whatever it does to devices
is generally incompatible with the device_resume() in (d) (because, for
instance, some device driver's .resume() routine may expect some data to be
saved by the corresponding .suspend() at specific locations).
ok, this means that the resume operation is not a solved problem (at least
for the kexec process)
now, one possible approach to this (and this may be what Ying Huang it
thinking of) would be to have the restore process be
1. boot the normal kernel with a dummy userspace, initializeing all
devices
2. kexec to the hibernate kernel
3. the hibernate kernel's userspace overwrites all memory from the
origional system that was saved
4. kexec from the hibernate kernel back to the origional kernel
the ugly part here is the need for the dummy userspace in step #1 so that
it doesn't try to access the wrong things.
now, it may be that the kernel boot in step 1 doesn't need to be able to
initialize all drivers for things to work in step 4, in which case things
are much simpler (but you still may need the three kernel hop so that the
final kernel is running in the same addresses that it started in.
David Lang
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
