All of lore.kernel.org
 help / color / mirror / Atom feed
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

             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.