From: "Mika Penttilä" <mika.penttila@kolumbus.fi>
To: huang ying <huang.ying.caritas@gmail.com>
Cc: nigel@nigel.suspend2.net,
Kexec Mailing List <kexec@lists.infradead.org>,
linux-kernel@vger.kernel.org,
"Eric W. Biederman" <ebiederm@xmission.com>,
Pavel Machek <pavel@ucw.cz>, "Huang, Ying" <ying.huang@intel.com>,
Andrew Morton <akpm@linux-foundation.org>,
linux-pm@lists.linux-foundation.org,
Jeremy Maitin-Shepard <jbms@cmu.edu>
Subject: Re: [linux-pm] [RFC][PATCH 0/2 -mm] kexec based hibernation -v3
Date: Fri, 21 Sep 2007 17:56:43 +0300 [thread overview]
Message-ID: <46F3DBAB.9010308@kolumbus.fi> (raw)
In-Reply-To: <851fc09e0709210644y4a859a2bp223ef56b08a27f0@mail.gmail.com>
huang ying wrote:
> On 9/21/07, Mika Penttilä <mika.penttila@kolumbus.fi> wrote:
>
>>> Usage:
>>>
>>> 1. Compile kernel with following options selected:
>>>
>>> CONFIG_X86_32=y
>>> CONFIG_RELOCATABLE=y # not needed strictly, but it is more convenient with it
>>> CONFIG_KEXEC=y
>>> CONFIG_CRASH_DUMP=y # only needed by kexeced kernel to save/restore memory image
>>> CONFIG_PM=y
>>> CONFIG_KEXEC_JUMP=y
>>>
>>> 2. Download the kexec-tools-testing git tree, apply the kexec-tools
>>> kjump patches (or download the source tar ball directly) and
>>> compile.
>>>
>>> 3. Download and compile the krestore tool.
>>>
>>> 4. Prepare 2 root partition used by kernel A and kernel B/C, referred
>>> as /dev/hda, /dev/hdb in following text. This is not strictly
>>> necessary, I use this scheme for testing during development.
>>>
>>> 5. Boot kernel compiled for normal usage (kernal A).
>>>
>>> 6. Load kernel compiled for hibernating/restore usage (kernel B) with
>>> kexec, the same kernel as that of 5 can be used if
>>> CONFIG_RELOCATABLE=y and CONFIG_CRASH_DUMP=y are selected.
>>>
>>> The --elf64-core-headers should be specified in command line of
>>> kexec, because only the 64bit ELF is supported by krestore tool.
>>>
>>> For example, the shell command line can be as follow:
>>>
>>> kexec -p -n /boot/bzImage --mem-min=0x100000 --mem-max=0xffffff
>>> --elf64-core-headers --append="root=/dev/hdb single"
>>>
>>> 7. Jump to the hibernating kernel (kernel B) with following shell
>>> command line:
>>>
>>> kexec -j
>>>
>>> 8. In the hibernating kernel (kernel B), the memory image of
>>> hibernated kernel (kernel A) can be saved as follow:
>>>
>>> cp /proc/vmcore .
>>> cp /sys/kernel/kexec_jump_back_entry .
>>>
>>>
>> Here we save also kernel B's pages.
>>
>
> No, the kernel B's pages will not be saved. Because when we build the
> elfcore (/proc/vmcore) header, we exclude memory area used by kernel
> B. The details can be found in kexec-tools patches.
>
>
Ok I see. But should the kernel B's e820 mem map be limited to 1m-16m in
order not to allocate pages found also in A's space? Or does does the
--mem-min and --mem-max do that also?
Thanks,
Mika
_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
WARNING: multiple messages have this Message-ID (diff)
From: "Mika Penttilä" <mika.penttila@kolumbus.fi>
To: huang ying <huang.ying.caritas@gmail.com>
Cc: "Huang, Ying" <ying.huang@intel.com>,
"Eric W. Biederman" <ebiederm@xmission.com>,
Pavel Machek <pavel@ucw.cz>,
nigel@nigel.suspend2.net,
Andrew Morton <akpm@linux-foundation.org>,
Jeremy Maitin-Shepard <jbms@cmu.edu>,
linux-pm@lists.linux-foundation.org,
Kexec Mailing List <kexec@lists.infradead.org>,
linux-kernel@vger.kernel.org
Subject: Re: [linux-pm] [RFC][PATCH 0/2 -mm] kexec based hibernation -v3
Date: Fri, 21 Sep 2007 17:56:43 +0300 [thread overview]
Message-ID: <46F3DBAB.9010308@kolumbus.fi> (raw)
In-Reply-To: <851fc09e0709210644y4a859a2bp223ef56b08a27f0@mail.gmail.com>
huang ying wrote:
> On 9/21/07, Mika Penttilä <mika.penttila@kolumbus.fi> wrote:
>
>>> Usage:
>>>
>>> 1. Compile kernel with following options selected:
>>>
>>> CONFIG_X86_32=y
>>> CONFIG_RELOCATABLE=y # not needed strictly, but it is more convenient with it
>>> CONFIG_KEXEC=y
>>> CONFIG_CRASH_DUMP=y # only needed by kexeced kernel to save/restore memory image
>>> CONFIG_PM=y
>>> CONFIG_KEXEC_JUMP=y
>>>
>>> 2. Download the kexec-tools-testing git tree, apply the kexec-tools
>>> kjump patches (or download the source tar ball directly) and
>>> compile.
>>>
>>> 3. Download and compile the krestore tool.
>>>
>>> 4. Prepare 2 root partition used by kernel A and kernel B/C, referred
>>> as /dev/hda, /dev/hdb in following text. This is not strictly
>>> necessary, I use this scheme for testing during development.
>>>
>>> 5. Boot kernel compiled for normal usage (kernal A).
>>>
>>> 6. Load kernel compiled for hibernating/restore usage (kernel B) with
>>> kexec, the same kernel as that of 5 can be used if
>>> CONFIG_RELOCATABLE=y and CONFIG_CRASH_DUMP=y are selected.
>>>
>>> The --elf64-core-headers should be specified in command line of
>>> kexec, because only the 64bit ELF is supported by krestore tool.
>>>
>>> For example, the shell command line can be as follow:
>>>
>>> kexec -p -n /boot/bzImage --mem-min=0x100000 --mem-max=0xffffff
>>> --elf64-core-headers --append="root=/dev/hdb single"
>>>
>>> 7. Jump to the hibernating kernel (kernel B) with following shell
>>> command line:
>>>
>>> kexec -j
>>>
>>> 8. In the hibernating kernel (kernel B), the memory image of
>>> hibernated kernel (kernel A) can be saved as follow:
>>>
>>> cp /proc/vmcore .
>>> cp /sys/kernel/kexec_jump_back_entry .
>>>
>>>
>> Here we save also kernel B's pages.
>>
>
> No, the kernel B's pages will not be saved. Because when we build the
> elfcore (/proc/vmcore) header, we exclude memory area used by kernel
> B. The details can be found in kexec-tools patches.
>
>
Ok I see. But should the kernel B's e820 mem map be limited to 1m-16m in
order not to allocate pages found also in A's space? Or does does the
--mem-min and --mem-max do that also?
Thanks,
Mika
next prev parent reply other threads:[~2007-09-21 15:04 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-09-20 5:34 [RFC][PATCH 0/2 -mm] kexec based hibernation -v3 Huang, Ying
2007-09-20 5:34 ` Huang, Ying
2007-09-21 8:43 ` Stefan Rompf
2007-09-21 8:43 ` [linux-pm] " Stefan Rompf
2007-09-21 8:43 ` Stefan Rompf
2007-09-21 8:47 ` Huang, Ying
2007-09-21 8:47 ` Huang, Ying
2007-09-21 8:47 ` Huang, Ying
2007-09-21 9:47 ` Mika Penttilä
2007-09-21 9:47 ` [linux-pm] " Mika Penttilä
2007-09-21 9:47 ` Mika Penttilä
2007-09-21 13:44 ` huang ying
2007-09-21 13:44 ` huang ying
2007-09-21 14:56 ` Mika Penttilä
2007-09-21 14:56 ` Mika Penttilä [this message]
2007-09-21 14:56 ` [linux-pm] " Mika Penttilä
2007-09-21 15:13 ` huang ying
2007-09-21 15:13 ` huang ying
2007-09-21 15:13 ` [linux-pm] " Mika Penttilä
2007-09-21 15:13 ` Mika Penttilä
2007-09-21 15:41 ` huang ying
2007-09-21 15:41 ` huang ying
2007-09-21 15:13 ` Mika Penttilä
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=46F3DBAB.9010308@kolumbus.fi \
--to=mika.penttila@kolumbus.fi \
--cc=akpm@linux-foundation.org \
--cc=ebiederm@xmission.com \
--cc=huang.ying.caritas@gmail.com \
--cc=jbms@cmu.edu \
--cc=kexec@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pm@lists.linux-foundation.org \
--cc=nigel@nigel.suspend2.net \
--cc=pavel@ucw.cz \
--cc=ying.huang@intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.