Re: [PATCH] Only reset e820 once, even with multiple memmap=exactmap params

From: Yinghai Lu <yinghai@kernel.org>
To: Thomas Renninger <trenn@suse.de>
Cc: MUNEDA Takahiro <muneda.takahiro@jp.fujitsu.com>,
	Takao Indoh <indou.takao@jp.fujitsu.com>,
	linux-pci@vger.kernel.org, x86@kernel.org,
	linux-kernel@vger.kernel.org, andi@firstfloor.org,
	tokunaga.keiich@jp.fujitsu.com, kexec@lists.infradead.org,
	hbabu@us.ibm.com, mingo@redhat.com, ddutile@redhat.com,
	vgoyal@redhat.com, ishii.hironobu@jp.fujitsu.com, hpa@zytor.com,
	bhelgaas@google.com, tglx@linutronix.de, khalid@gonehiking.org,
	horms@verge.net.au
Subject: Re: [PATCH] Only reset e820 once, even with multiple memmap=exactmap params
Date: Thu, 10 Jan 2013 15:34:37 -0800	[thread overview]
Message-ID: <CAE9FiQVLVxj07TM1N6F2kmZdBYMUiS6Xz2bD-JZPtvps3a5-xw@mail.gmail.com> (raw)
In-Reply-To: <1586060.uJlkOEQfVW@hammer82.arch.suse.de>

[-- Attachment #1: Type: text/plain, Size: 1730 bytes --]

On Wed, Jan 9, 2013 at 7:21 PM, Thomas Renninger <trenn@suse.de> wrote:
> I still do not understand why:
>
> Kexec (kexec/firmware_memmap.c) is setting up the e820 map from:
> /sys/firmware/memmap/*
> and pass it via bootloader structures.
> And this e820 table gets immediately voided by memmap=exactmap
> and a new one passed via boot parameters is set up.
> If I read this correctly, this is what happens?

yes, kdump scripts append those memmap.

>
> Can kexec simply pass the memory to use via memmap=X@Y
> Then take the original e820 table, but not the usable entries (those
> are coming from above memmap=X@Y).
> That would mean that the kexec kernel takes all the
> original ACPI, ACPI NVS, reserved, unusable (everthing but usable) entries
> from the original e820 table and identifies the usable memory from
> memmap boot param?

kdump scripts already do that for acpi regions, need to update it
to append that for mmconf.

>
> This would be much smarter than trying to pass the mmconf reserved
> area and I could imagine other issues will show up if the reserved areas
> do not match the original ones in the kexec kernel.
>
> If this really can be done and memmap=exactmap was only used by kexec,
> it's logic could be redefined from "drop all e820 entries" to
> "drop all usable e820 entries" and no further adjustings in kexec/kernel are
> needed to get mmconf working (and other issues may be avoided before
> they happen). Beside that ACPI reserved aread is not needed anymore to get
> passed via memmap=X#Y by kexec.

yes, we have other user for debug  like simulating user memmap for some bugs.

current problem for exactmap is that we don't scan that at first.

attached patch could help that.

Thanks

Yinghai

[-- Attachment #2: parse_exactmap_one_time.patch --]
[-- Type: application/octet-stream, Size: 1019 bytes --]

---
 arch/x86/kernel/e820.c |   12 ++++++++++++
 1 file changed, 12 insertions(+)

Index: linux-2.6/arch/x86/kernel/e820.c
===================================================================

--- linux-2.6.orig/arch/x86/kernel/e820.c
+++ linux-2.6/arch/x86/kernel/e820.c
@@ -835,6 +835,8 @@ static int __init parse_memopt(char *p)
 }
 early_param("mem", parse_memopt);
 
+static bool __initdata exactmap_parsed;
+
 static int __init parse_memmap_one(char *p)
 {
 	char *oldp;
@@ -844,6 +846,10 @@ static int __init parse_memmap_one(char
 		return -EINVAL;
 
 	if (!strncmp(p, "exactmap", 8)) {
+		if (exactmap_parsed)
+			return 0;
+
+		exactmap_parsed = true;
 #ifdef CONFIG_CRASH_DUMP
 		/*
 		 * If we are doing a crash dump, we still need to know
@@ -879,6 +885,12 @@ static int __init parse_memmap_one(char
 }
 static int __init parse_memmap_opt(char *str)
 {
+	char *p = boot_command_line;
+
+	p = strstr(p, "exactmap");
+	if (p)
+		parse_memmap_one("exactmap");
+
 	while (str) {
 		char *k = strchr(str, ',');
 
