From: "Huang, Ying" <ying.huang@intel.com>
To: Kexec Mailing List <kexec@lists.infradead.org>
Subject: crash by normal: crashdump without reserving memory during system boot
Date: Wed, 26 Sep 2007 15:34:10 +0800 [thread overview]
Message-ID: <1190792050.21818.284.camel@caritas-dev.intel.com> (raw)
Hi,
I have a proposal to do crashdump without reserving memory during system
boot. The method is as follow:
1. Do not reserve memory during system boot, that is
crashkernel=<XX>@<YY> is not used in kernel command line.
2. A new kexec flag named KEXEC_CRASH_BY_NORMAL is defined for
sys_kexec_load system call. When this flag is specified, the
sys_kexec_load works as normal kexec (not crash kexec), except the
destination image is kexec_crash_image instead of kexec_image.
3. In kexec-tools (/sbin/kexec), --mem-min=<addr1> and --mem-max=<addr2>
is used to specify the memory area used by crashdump kernel. That is,
the image, elf core header, available memory of crashdump kernel is
within <addr1> ~ <addr2>.
4. In kexec-tools, in addition to kernel image, elf core header, etc are
loaded, the available memory of crashdump kernel is loaded too. For
example, the segments for sys_kexec_load for crashdump kernel can be:
--mem-min=0x100000
--mem-max=0xffffff
No. buf bufsz mem memsz
0 NULL 0 0x1000 0x9e000
1 0x881fe88 0x289b 0x100000 0x3000
2 NULL 0 0x103000 0xfd000
3 0xb7bfa808 0xb7c00 0x200000 0xb8000
4 NULL 0 0x2b8000 0xd39000
5 0x8818d38 0x7120 0xff1000 0x9000
6 NULL 0 0xffa000 0x1000
7 0x8818268 0x400 0xffb000 0x4000
8 NULL 0 0xfff000 0x1000
5. In relocate_kernel of Linux kernel, instead of copy the source page
to destination page, the contents of source page and the destination
page are swapped. (The destination page -> source page map is in
kexec_crash_image->head) The memory area used by crashdump kernel is
backupped to source page.
In original crashdump implementation, the crashdump kernel run in
reserved memory area. The reserved memory pages are reserved memory
pages in primary (original) kernel.
In this proposed implementation, the crashdump kernel run in specified
memory area, the contents of destination memory area is backupped before
crashdump kernel running. The backup pages are allocated memory pages in
primary (original) kernel.
The pros and cons of proposed implementation:
Pros:
- The memory used by crashdump kernel need not to be reserved during
boot time.
- The memory used by crashdump kernel can be specified during
sys_kexec_load
- The memory used by crashdump kernel can be freed after unloading.
Cons:
- The memory used by crashdump kernel can be the DMA destination, their
contents may be ruined by devices during the boot of crashdump kernel.
(Is it possible to turn off DMA for some memory area other than
reserving it?)
In fact, almost all mechanism for this proposal has been implemented by
my previous patch: "kexec jump" in "kexec based hibernation".
Any comment is welcome.
Best Regards,
Huang Ying
_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
next reply other threads:[~2007-09-26 7:32 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-09-26 7:34 Huang, Ying [this message]
2007-10-01 8:40 ` crash by normal: crashdump without reserving memory during system boot Vivek Goyal
2007-10-09 13:28 ` Huang, Ying
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=1190792050.21818.284.camel@caritas-dev.intel.com \
--to=ying.huang@intel.com \
--cc=kexec@lists.infradead.org \
/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.