From: Linn Crosetto <linn@hp.com>
To: WANG Chao <chaowang@redhat.com>
Cc: "kexec@lists.infradead.org" <kexec@lists.infradead.org>,
"horms@verge.net.au" <horms@verge.net.au>,
"ebiederm@xmission.com" <ebiederm@xmission.com>,
"hpa@zytor.com" <hpa@zytor.com>,
"dyoung@redhat.com" <dyoung@redhat.com>,
"trenn@suse.de" <trenn@suse.de>,
"vgoyal@redhat.com" <vgoyal@redhat.com>
Subject: Re: [PATCH v2 4/4] x86: Pass memory range via E820 for kdump
Date: Thu, 27 Feb 2014 13:53:12 -0700 [thread overview]
Message-ID: <20140227205312.GJ30210@oranje.fc.hp.com> (raw)
In-Reply-To: <1392888512-4473-5-git-send-email-chaowang@redhat.com>
Hi Chao,
On Thu, Feb 20, 2014 at 02:28:32AM -0700, WANG Chao wrote:
[..]
> +static void setup_e820_ext(struct kexec_info *info, struct x86_linux_param_header *real_mode,
> + struct memory_range *range, int nr_range)
> +{
> + struct setup_data *sd;
> + struct e820entry *e820;
> + int i, j, nr_range_ext;
> +
> + nr_range_ext = nr_range - E820MAX;
> + sd = malloc(sizeof(struct setup_data) + nr_range_ext * sizeof(struct e820entry));
> + sd->next = 0;
> + sd->len = nr_range_ext * sizeof(struct e820entry);
> + sd->type = SETUP_E820_EXT;
> +
> + e820 = (struct e820entry *) sd->data;
> + dbgprintf("Extended E820 via setup_data:\n");
> + for(i = 0, j = E820MAX; i < nr_range_ext; i++, j++) {
> + e820[i].addr = range[j].start;
> + e820[i].size = range[j].end - range[j].start;
> + switch (range[j].type) {
> + case RANGE_RAM:
> + e820[i].type = E820_RAM;
> + break;
> + case RANGE_ACPI:
> + e820[i].type = E820_ACPI;
> + break;
> + case RANGE_ACPI_NVS:
> + e820[i].type = E820_NVS;
> + break;
> + default:
> + case RANGE_RESERVED:
> + e820[i].type = E820_RESERVED;
> + break;
> + }
> + dbgprintf("%016lx-%016lx (%d)\n",
> + e820[i].addr,
> + e820[i].addr + e820[i].size - 1,
> + e820[i].type);
> +
> + if (range[j].type != RANGE_RAM)
> + continue;
> + if ((range[j].start <= 0x100000) && range[j].end > 0x100000) {
> + unsigned long long mem_k = (range[j].end >> 10) - (0x100000 >> 10);
> + real_mode->ext_mem_k = mem_k;
> + real_mode->alt_mem_k = mem_k;
> + if (mem_k > 0xfc00) {
> + real_mode->ext_mem_k = 0xfc00; /* 64M */
> + }
> + if (mem_k > 0xffffffff) {
> + real_mode->alt_mem_k = 0xffffffff;
> + }
> + }
> + }
> + add_setup_data(info, real_mode, sd);
> + free(sd);
Remove this call to free(sd) or the kernel will not boot if there are more than
E820MAX entries.
> +}
> +
> +static void setup_e820(struct kexec_info *info, struct x86_linux_param_header *real_mode,
> + struct memory_range *range, int nr_range)
> +{
> +
> + int nr_range_saved = nr_range;
> + int i;
> +
> + if (nr_range > E820MAX) {
> + nr_range = E820MAX;
> + }
> +
> + real_mode->e820_map_nr = nr_range;
> + dbgprintf("E820 memmap:\n");
> + for(i = 0; i < nr_range; i++) {
> + real_mode->e820_map[i].addr = range[i].start;
> + real_mode->e820_map[i].size = range[i].end - range[i].start;
> + switch (range[i].type) {
> + case RANGE_RAM:
> + real_mode->e820_map[i].type = E820_RAM;
> + break;
> + case RANGE_ACPI:
> + real_mode->e820_map[i].type = E820_ACPI;
> + break;
> + case RANGE_ACPI_NVS:
> + real_mode->e820_map[i].type = E820_NVS;
> + break;
> + default:
> + case RANGE_RESERVED:
> + real_mode->e820_map[i].type = E820_RESERVED;
> + break;
> + }
> + dbgprintf("%016lx-%016lx (%d)\n",
> + real_mode->e820_map[i].addr,
> + real_mode->e820_map[i].addr + real_mode->e820_map[i].size - 1,
> + real_mode->e820_map[i].type);
> +
> + if (range[i].type != RANGE_RAM)
> + continue;
> + if ((range[i].start <= 0x100000) && range[i].end > 0x100000) {
> + unsigned long long mem_k = (range[i].end >> 10) - (0x100000 >> 10);
> + real_mode->ext_mem_k = mem_k;
> + real_mode->alt_mem_k = mem_k;
> + if (mem_k > 0xfc00) {
> + real_mode->ext_mem_k = 0xfc00; /* 64M */
> + }
> + if (mem_k > 0xffffffff) {
> + real_mode->alt_mem_k = 0xffffffff;
> + }
> + }
> + }
> +
> + if (nr_range_saved > E820MAX) {
> + dbgprintf("extra E820 memmap are passed via setup_data\n");
> + setup_e820_ext(info, real_mode, range, nr_range_saved);
> + }
> +}
> +
setup_e820() and setup_e820_ext() contain a lot of duplication. You could
combine them into a single function, similar to the implementation of
setup_e820() in the kernel.
> static int
> get_efi_mem_desc_version(struct x86_linux_param_header *real_mode)
> {
> @@ -704,7 +830,7 @@ void setup_linux_system_parameters(struct kexec_info *info,
[..]
> + if (info->kexec_flags & KEXEC_ON_CRASH && !pass_memmap_cmdline) {
> + range = crash_memory_range;
> + ranges = crash_memory_ranges;
> + } else {
> + range = info->memory_range;
> + ranges = info->memory_ranges;
> }
You can move this code into setup_e820(), since range and ranges are not used
elsewhere in setup_linux_system_parameters().
> + setup_e820(info, real_mode, range, ranges);
>
> /* fill the EDD information */
> setup_edd_info(real_mode);
> --
> 1.8.5.3
I tested boot (with the above fix) on a system with a large memory map, and can
easily test changes, if needed.
Thanks,
Linn
_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
next prev parent reply other threads:[~2014-02-27 20:53 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-02-20 9:28 [PATCH v2 0/4] kexec-tools, x86: E820 memmap pass for kdump WANG Chao
2014-02-20 9:28 ` [PATCH v2 1/4] cleanup: add dbgprint_mem_range function WANG Chao
2014-02-20 9:28 ` [PATCH v2 2/4] x86: Store memory ranges globally used for crash kernel to boot into WANG Chao
2014-02-20 9:28 ` [PATCH v2 3/4] x86: add --pass-memmap-cmdline option WANG Chao
2014-02-20 9:28 ` [PATCH v2 4/4] x86: Pass memory range via E820 for kdump WANG Chao
2014-02-27 20:53 ` Linn Crosetto [this message]
2014-02-28 8:32 ` WANG Chao
2014-02-24 10:38 ` [PATCH v2 0/4] kexec-tools, x86: E820 memmap pass " Thomas Renninger
2014-02-24 14:58 ` WANG Chao
2014-02-24 15:03 ` H. Peter Anvin
2014-02-24 15:11 ` Vivek Goyal
2014-02-24 15:24 ` Vivek Goyal
2014-02-24 15:28 ` H. Peter Anvin
2014-02-24 15:22 ` Vivek Goyal
2014-02-24 15:27 ` H. Peter Anvin
2014-02-24 15:34 ` Thomas Renninger
2014-02-24 15:45 ` Vivek Goyal
2014-02-24 15:50 ` H. Peter Anvin
2014-02-24 15:59 ` Vivek Goyal
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=20140227205312.GJ30210@oranje.fc.hp.com \
--to=linn@hp.com \
--cc=chaowang@redhat.com \
--cc=dyoung@redhat.com \
--cc=ebiederm@xmission.com \
--cc=horms@verge.net.au \
--cc=hpa@zytor.com \
--cc=kexec@lists.infradead.org \
--cc=trenn@suse.de \
--cc=vgoyal@redhat.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox