linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* [PATCH -v3 0/4] x86, kdump: Fix crashkernel high with old kexec-tools
@ 2013-04-04 22:16 Yinghai Lu
  2013-04-04 22:16 ` [PATCH v3 1/4] x86, kdump: Set crashkernel_low automatically Yinghai Lu
                   ` (3 more replies)
  0 siblings, 4 replies; 20+ messages in thread
From: Yinghai Lu @ 2013-04-04 22:16 UTC (permalink / raw)
  To: Thomas Gleixner, Ingo Molnar, H. Peter Anvin
  Cc: WANG Chao, Vivek Goyal, Eric W. Biederman, linux-kernel

Vivek found some problems with old kexec-tools.

We keep the old crashkernel=X to old behavoir, so it will not break
old kexec-tools.
Add crashkernel=X,high to support new kexec-tools that supports loading high.
when high is used, memblock will search from top to low.
if the allocated one is above 4G, kernel will try to auto allocate
72M under 4G for swiotlb.
user could crashkernel=Y,low to change 72M to other value.

-v2:	reorder the patch sequences
	crashkernel=X,high, crashkernel=Y,low only handle simple form.
	crashkernel=X will override crashkernel=X;high crashkernel=Y;low
-v3:	update description in kernel-parameters.txt
	update get_last_crashkernel and _simple checking about suffix.

Thanks

Yinghai

^ permalink raw reply	[flat|nested] 20+ messages in thread

* [PATCH v3 1/4] x86, kdump: Set crashkernel_low automatically
  2013-04-04 22:16 [PATCH -v3 0/4] x86, kdump: Fix crashkernel high with old kexec-tools Yinghai Lu
@ 2013-04-04 22:16 ` Yinghai Lu
  2013-04-08  7:09   ` Dave Young
  2013-04-04 22:16 ` [PATCH v3 4/4] kexec: use Crash kernel for Crash kernel low Yinghai Lu
                   ` (2 subsequent siblings)
  3 siblings, 1 reply; 20+ messages in thread
From: Yinghai Lu @ 2013-04-04 22:16 UTC (permalink / raw)
  To: Thomas Gleixner, Ingo Molnar, H. Peter Anvin
  Cc: WANG Chao, Vivek Goyal, Eric W. Biederman, linux-kernel, Yinghai Lu

Chao said that kdump does does work well on his system on 3.8
without extra parameter, even iommu does not work with kdump.
And now have to append crashkernel_low=Y in first kernel to make
kdump work.

We have now modified crashkernel=X to allocate memory beyong 4G (if
available) and do not allocate low range for crashkernel if the user
does not specify that with crashkernel_low=Y.  This causes regression
if iommu is not enabled.  Without iommu, swiotlb needs to be setup in
first 4G and there is no low memory available to second kernel.

Set crashkernel_low automatically if the user does not specify that.

For system that does support IOMMU with kdump properly, user could
specify crashkernel_low=0 to save that 72M low ram.

-v3: add swiotlb_size() according to Konrad.
-v4: add comments what 8M is for according to hpa.
     also update more crashkernel_low= in kernel-parameters.txt
-v5: update changelog according to Vivek.
-v6: Change description about swiotlb referring according to HATAYAMA.

Reported-by: WANG Chao <chaowang@redhat.com>
Tested-by: WANG Chao <chaowang@redhat.com>
Signed-off-by: Yinghai Lu <yinghai@kernel.org>

---
 Documentation/kernel-parameters.txt |   14 +++++++++++---
 arch/x86/kernel/setup.c             |   20 +++++++++++++++++---
 include/linux/swiotlb.h             |    1 +
 lib/swiotlb.c                       |   19 +++++++++++++++----
 4 files changed, 44 insertions(+), 10 deletions(-)

Index: linux-2.6/arch/x86/kernel/setup.c
===================================================================
--- linux-2.6.orig/arch/x86/kernel/setup.c
+++ linux-2.6/arch/x86/kernel/setup.c
@@ -519,19 +519,33 @@ static void __init reserve_crashkernel_l
 	unsigned long long low_base = 0, low_size = 0;
 	unsigned long total_low_mem;
 	unsigned long long base;
+	bool auto_set = false;
 	int ret;
 
 	total_low_mem = memblock_mem_size(1UL<<(32-PAGE_SHIFT));
 	ret = parse_crashkernel_low(boot_command_line, total_low_mem,
 						&low_size, &base);
-	if (ret != 0 || low_size <= 0)
-		return;
+	if (ret != 0) {
+		/*
+		 * two parts from lib/swiotlb.c:
+		 *	swiotlb size: user specified with swiotlb= or default.
+		 *	swiotlb overflow buffer: now is hardcoded to 32k,
+		 *		round to 8M to cover more others.
+		 */
+		low_size = swiotlb_size_or_default() + (8UL<<20);
+		auto_set = true;
+	} else {
+		/* passed with crashkernel_low=0 ? */
+		if (!low_size)
+			return;
+	}
 
 	low_base = memblock_find_in_range(low_size, (1ULL<<32),
 					low_size, alignment);
 
 	if (!low_base) {
-		pr_info("crashkernel low reservation failed - No suitable area found.\n");
+		if (!auto_set)
+			pr_info("crashkernel low reservation failed - No suitable area found.\n");
 
 		return;
 	}
Index: linux-2.6/include/linux/swiotlb.h
===================================================================
--- linux-2.6.orig/include/linux/swiotlb.h
+++ linux-2.6/include/linux/swiotlb.h
@@ -25,6 +25,7 @@ extern int swiotlb_force;
 extern void swiotlb_init(int verbose);
 int swiotlb_init_with_tbl(char *tlb, unsigned long nslabs, int verbose);
 extern unsigned long swiotlb_nr_tbl(void);
+unsigned long swiotlb_size_or_default(void);
 extern int swiotlb_late_init_with_tbl(char *tlb, unsigned long nslabs);
 
 /*
Index: linux-2.6/lib/swiotlb.c
===================================================================
--- linux-2.6.orig/lib/swiotlb.c
+++ linux-2.6/lib/swiotlb.c
@@ -105,9 +105,9 @@ setup_io_tlb_npages(char *str)
 	if (!strcmp(str, "force"))
 		swiotlb_force = 1;
 
-	return 1;
+	return 0;
 }
-__setup("swiotlb=", setup_io_tlb_npages);
+early_param("swiotlb", setup_io_tlb_npages);
 /* make io_tlb_overflow tunable too? */
 
 unsigned long swiotlb_nr_tbl(void)
@@ -115,6 +115,18 @@ unsigned long swiotlb_nr_tbl(void)
 	return io_tlb_nslabs;
 }
 EXPORT_SYMBOL_GPL(swiotlb_nr_tbl);
+
+/* default to 64MB */
+#define IO_TLB_DEFAULT_SIZE (64UL<<20)
+unsigned long swiotlb_size_or_default(void)
+{
+	unsigned long size;
+
+	size = io_tlb_nslabs << IO_TLB_SHIFT;
+
+	return size ? size : (IO_TLB_DEFAULT_SIZE);
+}
+
 /* Note that this doesn't work with highmem page */
 static dma_addr_t swiotlb_virt_to_bus(struct device *hwdev,
 				      volatile void *address)
@@ -188,8 +200,7 @@ int __init swiotlb_init_with_tbl(char *t
 void  __init
 swiotlb_init(int verbose)
 {
-	/* default to 64MB */
-	size_t default_size = 64UL<<20;
+	size_t default_size = IO_TLB_DEFAULT_SIZE;
 	unsigned char *vstart;
 	unsigned long bytes;
 
Index: linux-2.6/Documentation/kernel-parameters.txt
===================================================================
--- linux-2.6.orig/Documentation/kernel-parameters.txt
+++ linux-2.6/Documentation/kernel-parameters.txt
@@ -596,9 +596,6 @@ bytes respectively. Such letter suffixes
 			is selected automatically. Check
 			Documentation/kdump/kdump.txt for further details.
 
-	crashkernel_low=size[KMG]
-			[KNL, x86] parts under 4G.
-
 	crashkernel=range1:size1[,range2:size2,...][@offset]
 			[KNL] Same as above, but depends on the memory
 			in the running system. The syntax of range is
@@ -606,6 +603,17 @@ bytes respectively. Such letter suffixes
 			a memory unit (amount[KMG]). See also
 			Documentation/kdump/kdump.txt for an example.
 
+	crashkernel_low=size[KMG]
+			[KNL, x86_64] range under 4G. When crashkernel= is
+			passed, kernel allocate physical memory region
+			above 4G, that cause second kernel crash on system
+			that require some amount of low memory, e.g. swiotlb
+			requires at least 64M+32K low memory.  Kernel would
+			try to allocate 72M below 4G automatically.
+			This one let user to specify own low range under 4G
+			for second kernel instead.
+			0: to disable low allocation.
+
 	cs89x0_dma=	[HW,NET]
 			Format: <dma>
 

^ permalink raw reply	[flat|nested] 20+ messages in thread

* [PATCH v3 4/4] kexec: use Crash kernel for Crash kernel low
  2013-04-04 22:16 [PATCH -v3 0/4] x86, kdump: Fix crashkernel high with old kexec-tools Yinghai Lu
  2013-04-04 22:16 ` [PATCH v3 1/4] x86, kdump: Set crashkernel_low automatically Yinghai Lu
@ 2013-04-04 22:16 ` Yinghai Lu
  2013-04-04 22:17 ` [PATCH v3 2/4] x86, kdump: Retore crashkernel= to allocate under 896M Yinghai Lu
  2013-04-04 22:17 ` [PATCH v3 3/4] x86, kdump: Change crashkernel_high/low= to crashkernel=;high/low Yinghai Lu
  3 siblings, 0 replies; 20+ messages in thread
From: Yinghai Lu @ 2013-04-04 22:16 UTC (permalink / raw)
  To: Thomas Gleixner, Ingo Molnar, H. Peter Anvin
  Cc: WANG Chao, Vivek Goyal, Eric W. Biederman, linux-kernel, Yinghai Lu

We can extend kexec-tools to support multiple "Crash kernel" in /proc/iomem
instead.

So we can use "Crash kernel" instead of "Crash kernel low" in /proc/iomem.

Suggested-by: Vivek Goyal <vgoyal@redhat.com>
Signed-off-by: Yinghai Lu <yinghai@kernel.org>

---
 kernel/kexec.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

Index: linux-2.6/kernel/kexec.c
===================================================================
--- linux-2.6.orig/kernel/kexec.c
+++ linux-2.6/kernel/kexec.c
@@ -55,7 +55,7 @@ struct resource crashk_res = {
 	.flags = IORESOURCE_BUSY | IORESOURCE_MEM
 };
 struct resource crashk_low_res = {
-	.name  = "Crash kernel low",
+	.name  = "Crash kernel",
 	.start = 0,
 	.end   = 0,
 	.flags = IORESOURCE_BUSY | IORESOURCE_MEM

^ permalink raw reply	[flat|nested] 20+ messages in thread

* [PATCH v3 2/4] x86, kdump: Retore crashkernel= to allocate under 896M
  2013-04-04 22:16 [PATCH -v3 0/4] x86, kdump: Fix crashkernel high with old kexec-tools Yinghai Lu
  2013-04-04 22:16 ` [PATCH v3 1/4] x86, kdump: Set crashkernel_low automatically Yinghai Lu
  2013-04-04 22:16 ` [PATCH v3 4/4] kexec: use Crash kernel for Crash kernel low Yinghai Lu
@ 2013-04-04 22:17 ` Yinghai Lu
  2013-04-04 22:17 ` [PATCH v3 3/4] x86, kdump: Change crashkernel_high/low= to crashkernel=;high/low Yinghai Lu
  3 siblings, 0 replies; 20+ messages in thread
From: Yinghai Lu @ 2013-04-04 22:17 UTC (permalink / raw)
  To: Thomas Gleixner, Ingo Molnar, H. Peter Anvin
  Cc: WANG Chao, Vivek Goyal, Eric W. Biederman, linux-kernel, Yinghai Lu

Vivek found old kexec-tools does not work new kernel anymore.

So change back crashkernel= back to old behavoir, and add crashkernel_high=
to let user decide if buffer could be above 4G, and also new kexec-tools will
be needed.

-v2: let crashkernel=X override crashkernel_high=
    update description about _high will be ignored by crashkernel=X
-v3: update description about kernel-parameters.txt according to Vivek.

Signed-off-by: Yinghai Lu <yinghai@kernel.org>

---
 Documentation/kernel-parameters.txt |   13 +++++++++++--
 arch/x86/kernel/setup.c             |   24 +++++++++++++++++++-----
 include/linux/kexec.h               |    2 ++
 kernel/kexec.c                      |    9 +++++++++
 4 files changed, 41 insertions(+), 7 deletions(-)

Index: linux-2.6/Documentation/kernel-parameters.txt
===================================================================
--- linux-2.6.orig/Documentation/kernel-parameters.txt
+++ linux-2.6/Documentation/kernel-parameters.txt
@@ -603,9 +603,16 @@ bytes respectively. Such letter suffixes
 			a memory unit (amount[KMG]). See also
 			Documentation/kdump/kdump.txt for an example.
 
+	crashkernel_high=size[KMG]
+			[KNL, x86_64] range could be above 4G. Allow kernel
+			to allocate physical memory region from top, so could
+			be above 4G if system have more than 4G ram installed.
+			Otherwise memory region will be allocated below 4G, if
+			available.
+			It will be ignored if crashkernel=X is specified.
 	crashkernel_low=size[KMG]
-			[KNL, x86_64] range under 4G. When crashkernel= is
-			passed, kernel allocate physical memory region
+			[KNL, x86_64] range under 4G. When crashkernel_high= is
+			passed, kernel could allocate physical memory region
 			above 4G, that cause second kernel crash on system
 			that require some amount of low memory, e.g. swiotlb
 			requires at least 64M+32K low memory.  Kernel would
@@ -613,6 +620,8 @@ bytes respectively. Such letter suffixes
 			This one let user to specify own low range under 4G
 			for second kernel instead.
 			0: to disable low allocation.
+			It will be ignored when crashkernel_high=X is not used
+			or memory reserved is below 4G.
 
 	cs89x0_dma=	[HW,NET]
 			Format: <dma>
Index: linux-2.6/arch/x86/kernel/setup.c
===================================================================
--- linux-2.6.orig/arch/x86/kernel/setup.c
+++ linux-2.6/arch/x86/kernel/setup.c
@@ -505,11 +505,14 @@ static void __init memblock_x86_reserve_
 /*
  * Keep the crash kernel below this limit.  On 32 bits earlier kernels
  * would limit the kernel to the low 512 MiB due to mapping restrictions.
+ * On 64bit, old kexec-tools need to under 896MiB.
  */
 #ifdef CONFIG_X86_32
-# define CRASH_KERNEL_ADDR_MAX	(512 << 20)
+# define CRASH_KERNEL_ADDR_LOW_MAX	(512 << 20)
+# define CRASH_KERNEL_ADDR_HIGH_MAX	(512 << 20)
 #else
-# define CRASH_KERNEL_ADDR_MAX	MAXMEM
+# define CRASH_KERNEL_ADDR_LOW_MAX	(896UL<<20)
+# define CRASH_KERNEL_ADDR_HIGH_MAX	MAXMEM
 #endif
 
 static void __init reserve_crashkernel_low(void)
@@ -523,6 +526,7 @@ static void __init reserve_crashkernel_l
 	int ret;
 
 	total_low_mem = memblock_mem_size(1UL<<(32-PAGE_SHIFT));
+	/* crashkernel_low=YM */
 	ret = parse_crashkernel_low(boot_command_line, total_low_mem,
 						&low_size, &base);
 	if (ret != 0) {
@@ -566,14 +570,22 @@ static void __init reserve_crashkernel(v
 	const unsigned long long alignment = 16<<20;	/* 16M */
 	unsigned long long total_mem;
 	unsigned long long crash_size, crash_base;
+	bool high = false;
 	int ret;
 
 	total_mem = memblock_phys_mem_size();
 
+	/* crashkernel=XM */
 	ret = parse_crashkernel(boot_command_line, total_mem,
 			&crash_size, &crash_base);
-	if (ret != 0 || crash_size <= 0)
-		return;
+	if (ret != 0 || crash_size <= 0) {
+		/* crashkernel_high=XM */
+		ret = parse_crashkernel_high(boot_command_line, total_mem,
+				&crash_size, &crash_base);
+		if (ret != 0 || crash_size <= 0)
+			return;
+		high = true;
+	}
 
 	/* 0 means: find the address automatically */
 	if (crash_base <= 0) {
@@ -581,7 +593,9 @@ static void __init reserve_crashkernel(v
 		 *  kexec want bzImage is below CRASH_KERNEL_ADDR_MAX
 		 */
 		crash_base = memblock_find_in_range(alignment,
-			       CRASH_KERNEL_ADDR_MAX, crash_size, alignment);
+					high ? CRASH_KERNEL_ADDR_HIGH_MAX :
+					       CRASH_KERNEL_ADDR_LOW_MAX,
+					crash_size, alignment);
 
 		if (!crash_base) {
 			pr_info("crashkernel reservation failed - No suitable area found.\n");
Index: linux-2.6/include/linux/kexec.h
===================================================================
--- linux-2.6.orig/include/linux/kexec.h
+++ linux-2.6/include/linux/kexec.h
@@ -200,6 +200,8 @@ extern size_t vmcoreinfo_max_size;
 
 int __init parse_crashkernel(char *cmdline, unsigned long long system_ram,
 		unsigned long long *crash_size, unsigned long long *crash_base);
+int parse_crashkernel_high(char *cmdline, unsigned long long system_ram,
+		unsigned long long *crash_size, unsigned long long *crash_base);
 int parse_crashkernel_low(char *cmdline, unsigned long long system_ram,
 		unsigned long long *crash_size, unsigned long long *crash_base);
 int crash_shrink_memory(unsigned long new_size);
Index: linux-2.6/kernel/kexec.c
===================================================================
--- linux-2.6.orig/kernel/kexec.c
+++ linux-2.6/kernel/kexec.c
@@ -1422,6 +1422,15 @@ int __init parse_crashkernel(char *cmdli
 					"crashkernel=");
 }
 
+int __init parse_crashkernel_high(char *cmdline,
+			     unsigned long long system_ram,
+			     unsigned long long *crash_size,
+			     unsigned long long *crash_base)
+{
+	return __parse_crashkernel(cmdline, system_ram, crash_size, crash_base,
+					"crashkernel_high=");
+}
+
 int __init parse_crashkernel_low(char *cmdline,
 			     unsigned long long system_ram,
 			     unsigned long long *crash_size,

^ permalink raw reply	[flat|nested] 20+ messages in thread

* [PATCH v3 3/4] x86, kdump: Change crashkernel_high/low= to crashkernel=;high/low
  2013-04-04 22:16 [PATCH -v3 0/4] x86, kdump: Fix crashkernel high with old kexec-tools Yinghai Lu
                   ` (2 preceding siblings ...)
  2013-04-04 22:17 ` [PATCH v3 2/4] x86, kdump: Retore crashkernel= to allocate under 896M Yinghai Lu
@ 2013-04-04 22:17 ` Yinghai Lu
  2013-04-09 13:45   ` Vivek Goyal
  3 siblings, 1 reply; 20+ messages in thread
From: Yinghai Lu @ 2013-04-04 22:17 UTC (permalink / raw)
  To: Thomas Gleixner, Ingo Molnar, H. Peter Anvin
  Cc: WANG Chao, Vivek Goyal, Eric W. Biederman, linux-kernel, Yinghai Lu

Per hpa, use crashkernel=XM;high crashkernel=YM;low instead of
crashkernel_hign=XM crashkernel_low=YM. As that could be extensible.

-v2: according to Vivek, change delimiter to ;
-v3: let hign and low only handle simple form and it conforms to
	description in kernel-parameters.txt
     still keep crashkernel=X override any crashkernel=X,high
        crashkernel=Y,low
-v4: update get_last_crashkernel returning and add more strict
     checking in parse_crashkernel_simple() found by HATAYAMA.

Cc:HATAYAMA Daisuke <d.hatayama@jp.fujitsu.com>
Signed-off-by: Yinghai Lu <yinghai@kernel.org>

---
 Documentation/kernel-parameters.txt |   10 +--
 arch/x86/kernel/setup.c             |    6 +-
 kernel/kexec.c                      |  103 ++++++++++++++++++++++++++++--------
 3 files changed, 89 insertions(+), 30 deletions(-)

Index: linux-2.6/Documentation/kernel-parameters.txt
===================================================================
--- linux-2.6.orig/Documentation/kernel-parameters.txt
+++ linux-2.6/Documentation/kernel-parameters.txt
@@ -603,16 +603,16 @@ bytes respectively. Such letter suffixes
 			a memory unit (amount[KMG]). See also
 			Documentation/kdump/kdump.txt for an example.
 
-	crashkernel_high=size[KMG]
+	crashkernel=size[KMG];high
 			[KNL, x86_64] range could be above 4G. Allow kernel
 			to allocate physical memory region from top, so could
 			be above 4G if system have more than 4G ram installed.
 			Otherwise memory region will be allocated below 4G, if
 			available.
 			It will be ignored if crashkernel=X is specified.
-	crashkernel_low=size[KMG]
-			[KNL, x86_64] range under 4G. When crashkernel_high= is
-			passed, kernel could allocate physical memory region
+	crashkernel=size[KMG];low
+			[KNL, x86_64] range under 4G. When crashkernel=X;high
+			is passed, kernel could allocate physical memory region
 			above 4G, that cause second kernel crash on system
 			that require some amount of low memory, e.g. swiotlb
 			requires at least 64M+32K low memory.  Kernel would
@@ -620,7 +620,7 @@ bytes respectively. Such letter suffixes
 			This one let user to specify own low range under 4G
 			for second kernel instead.
 			0: to disable low allocation.
-			It will be ignored when crashkernel_high=X is not used
+			It will be ignored when crashkernel=X;high is not used
 			or memory reserved is below 4G.
 
 	cs89x0_dma=	[HW,NET]
Index: linux-2.6/arch/x86/kernel/setup.c
===================================================================
--- linux-2.6.orig/arch/x86/kernel/setup.c
+++ linux-2.6/arch/x86/kernel/setup.c
@@ -526,7 +526,7 @@ static void __init reserve_crashkernel_l
 	int ret;
 
 	total_low_mem = memblock_mem_size(1UL<<(32-PAGE_SHIFT));
-	/* crashkernel_low=YM */
+	/* crashkernel=YM;low */
 	ret = parse_crashkernel_low(boot_command_line, total_low_mem,
 						&low_size, &base);
 	if (ret != 0) {
@@ -539,7 +539,7 @@ static void __init reserve_crashkernel_l
 		low_size = swiotlb_size_or_default() + (8UL<<20);
 		auto_set = true;
 	} else {
-		/* passed with crashkernel_low=0 ? */
+		/* passed with crashkernel=0;low ? */
 		if (!low_size)
 			return;
 	}
@@ -579,7 +579,7 @@ static void __init reserve_crashkernel(v
 	ret = parse_crashkernel(boot_command_line, total_mem,
 			&crash_size, &crash_base);
 	if (ret != 0 || crash_size <= 0) {
-		/* crashkernel_high=XM */
+		/* crashkernel=XM;high */
 		ret = parse_crashkernel_high(boot_command_line, total_mem,
 				&crash_size, &crash_base);
 		if (ret != 0 || crash_size <= 0)
Index: linux-2.6/kernel/kexec.c
===================================================================
--- linux-2.6.orig/kernel/kexec.c
+++ linux-2.6/kernel/kexec.c
@@ -1339,6 +1339,15 @@ static int __init parse_crashkernel_mem(
 	return 0;
 }
 
+#define SUFFIX_HIGH 0
+#define SUFFIX_LOW  1
+#define SUFFIX_NULL 2
+static __initdata char *suffix_tbl[] = {
+	[SUFFIX_HIGH] = ";high",
+	[SUFFIX_LOW]  = ";low",
+	[SUFFIX_NULL] = NULL,
+};
+
 /*
  * That function parses "simple" (old) crashkernel command lines like
  *
@@ -1360,37 +1369,80 @@ static int __init parse_crashkernel_simp
 
 	if (*cur == '@')
 		*crash_base = memparse(cur+1, &cur);
-	else if (*cur != ' ' && *cur != '\0') {
-		pr_warning("crashkernel: unrecognized char\n");
-		return -EINVAL;
+	else {
+		int i;
+
+		/* check with known suffix */
+		for (i = 0; suffix_tbl[i]; i++)
+			if (!strncmp(cur, suffix_tbl[i], strlen(suffix_tbl[i])))
+				return 0;
+
+		if (*cur != ' ' && *cur != '\0') {
+			pr_warning("crashkernel: unrecognized char\n");
+			return -EINVAL;
+		}
 	}
 
 	return 0;
 }
 
-/*
- * That function is the entry point for command line parsing and should be
- * called from the arch-specific code.
- */
+static __init char *get_last_crashkernel(char *cmdline,
+			     const char *name,
+			     const char *suffix)
+{
+	char *p = cmdline, *ck_cmdline = NULL;
+
+	/* find crashkernel and use the last one if there are more */
+	p = strstr(p, name);
+	while (p) {
+		char *end_p = strchr(p, ' ');
+		char *q;
+
+		if (!end_p)
+			end_p = p + strlen(p);
+
+		if (!suffix) {
+			int i;
+
+			/* skip the one with any known suffix */
+			for (i = 0; suffix_tbl[i]; i++) {
+				q = end_p - strlen(suffix_tbl[i]);
+				if (!strncmp(q, suffix_tbl[i],
+					     strlen(suffix_tbl[i])))
+					goto next;
+			}
+			ck_cmdline = p;
+		} else {
+			q = end_p - strlen(suffix);
+			if (!strncmp(q, suffix, strlen(suffix)))
+				ck_cmdline = p;
+		}
+next:
+		p = strstr(p+1, name);
+	}
+
+	if (!ck_cmdline)
+		return NULL;
+
+	return ck_cmdline;
+}
+
 static int __init __parse_crashkernel(char *cmdline,
 			     unsigned long long system_ram,
 			     unsigned long long *crash_size,
 			     unsigned long long *crash_base,
-				const char *name)
+			     const char *name,
+			     const char *suffix,
+			     bool simple_only)
 {
-	char 	*p = cmdline, *ck_cmdline = NULL;
 	char	*first_colon, *first_space;
+	char	*ck_cmdline;
 
 	BUG_ON(!crash_size || !crash_base);
 	*crash_size = 0;
 	*crash_base = 0;
 
-	/* find crashkernel and use the last one if there are more */
-	p = strstr(p, name);
-	while (p) {
-		ck_cmdline = p;
-		p = strstr(p+1, name);
-	}
+	ck_cmdline = get_last_crashkernel(cmdline, name, suffix);
 
 	if (!ck_cmdline)
 		return -EINVAL;
@@ -1403,23 +1455,30 @@ static int __init __parse_crashkernel(ch
 	 */
 	first_colon = strchr(ck_cmdline, ':');
 	first_space = strchr(ck_cmdline, ' ');
-	if (first_colon && (!first_space || first_colon < first_space))
-		return parse_crashkernel_mem(ck_cmdline, system_ram,
-				crash_size, crash_base);
-	else
+	if (first_colon && (!first_space || first_colon < first_space)) {
+		if (simple_only)
+			return -EINVAL;
+		else
+			return parse_crashkernel_mem(ck_cmdline, system_ram,
+					crash_size, crash_base);
+	} else
 		return parse_crashkernel_simple(ck_cmdline, crash_size,
 				crash_base);
 
 	return 0;
 }
 
+/*
+ * That function is the entry point for command line parsing and should be
+ * called from the arch-specific code.
+ */
 int __init parse_crashkernel(char *cmdline,
 			     unsigned long long system_ram,
 			     unsigned long long *crash_size,
 			     unsigned long long *crash_base)
 {
 	return __parse_crashkernel(cmdline, system_ram, crash_size, crash_base,
-					"crashkernel=");
+					"crashkernel=", NULL, false);
 }
 
 int __init parse_crashkernel_high(char *cmdline,
@@ -1428,7 +1487,7 @@ int __init parse_crashkernel_high(char *
 			     unsigned long long *crash_base)
 {
 	return __parse_crashkernel(cmdline, system_ram, crash_size, crash_base,
-					"crashkernel_high=");
+				"crashkernel=", suffix_tbl[SUFFIX_HIGH], true);
 }
 
 int __init parse_crashkernel_low(char *cmdline,
@@ -1437,7 +1496,7 @@ int __init parse_crashkernel_low(char *c
 			     unsigned long long *crash_base)
 {
 	return __parse_crashkernel(cmdline, system_ram, crash_size, crash_base,
-					"crashkernel_low=");
+				"crashkernel=", suffix_tbl[SUFFIX_LOW], true);
 }
 
 static void update_vmcoreinfo_note(void)

^ permalink raw reply	[flat|nested] 20+ messages in thread

* Re: [PATCH v3 1/4] x86, kdump: Set crashkernel_low automatically
  2013-04-04 22:16 ` [PATCH v3 1/4] x86, kdump: Set crashkernel_low automatically Yinghai Lu
@ 2013-04-08  7:09   ` Dave Young
  2013-04-08 18:37     ` Yinghai Lu
  0 siblings, 1 reply; 20+ messages in thread
From: Dave Young @ 2013-04-08  7:09 UTC (permalink / raw)
  To: Yinghai Lu
  Cc: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, WANG Chao,
	Vivek Goyal, Eric W. Biederman, linux-kernel

On 04/05/2013 06:16 AM, Yinghai Lu wrote:
> Chao said that kdump does does work well on his system on 3.8
> without extra parameter, even iommu does not work with kdump.
> And now have to append crashkernel_low=Y in first kernel to make
> kdump work.
> 
> We have now modified crashkernel=X to allocate memory beyong 4G (if
> available) and do not allocate low range for crashkernel if the user
> does not specify that with crashkernel_low=Y.  This causes regression
> if iommu is not enabled.  Without iommu, swiotlb needs to be setup in
> first 4G and there is no low memory available to second kernel.

Is it possible to reuse the 1st kernel swiotlb region in 2nd capture
kernel if it's available?

> 
> Set crashkernel_low automatically if the user does not specify that.
> 
> For system that does support IOMMU with kdump properly, user could
> specify crashkernel_low=0 to save that 72M low ram.

How about make swiotlb size tunable in 1st kernel as well such as adding
a swiotlb_size= to cmdline, if it's set in 1st kernel crashkernel
reserving code can take it automaticlly.

This will benefit to user who use low-mem machines.

> 
> -v3: add swiotlb_size() according to Konrad.
> -v4: add comments what 8M is for according to hpa.
>      also update more crashkernel_low= in kernel-parameters.txt
> -v5: update changelog according to Vivek.
> -v6: Change description about swiotlb referring according to HATAYAMA.
> 
> Reported-by: WANG Chao <chaowang@redhat.com>
> Tested-by: WANG Chao <chaowang@redhat.com>
> Signed-off-by: Yinghai Lu <yinghai@kernel.org>
> 
> ---
>  Documentation/kernel-parameters.txt |   14 +++++++++++---
>  arch/x86/kernel/setup.c             |   20 +++++++++++++++++---
>  include/linux/swiotlb.h             |    1 +
>  lib/swiotlb.c                       |   19 +++++++++++++++----
>  4 files changed, 44 insertions(+), 10 deletions(-)
> 
> Index: linux-2.6/arch/x86/kernel/setup.c
> ===================================================================
> --- linux-2.6.orig/arch/x86/kernel/setup.c
> +++ linux-2.6/arch/x86/kernel/setup.c
> @@ -519,19 +519,33 @@ static void __init reserve_crashkernel_l
>  	unsigned long long low_base = 0, low_size = 0;
>  	unsigned long total_low_mem;
>  	unsigned long long base;
> +	bool auto_set = false;
>  	int ret;
>  
>  	total_low_mem = memblock_mem_size(1UL<<(32-PAGE_SHIFT));
>  	ret = parse_crashkernel_low(boot_command_line, total_low_mem,
>  						&low_size, &base);
> -	if (ret != 0 || low_size <= 0)
> -		return;
> +	if (ret != 0) {
> +		/*
> +		 * two parts from lib/swiotlb.c:
> +		 *	swiotlb size: user specified with swiotlb= or default.
> +		 *	swiotlb overflow buffer: now is hardcoded to 32k,
> +		 *		round to 8M to cover more others.
> +		 */
> +		low_size = swiotlb_size_or_default() + (8UL<<20);
> +		auto_set = true;
> +	} else {
> +		/* passed with crashkernel_low=0 ? */
> +		if (!low_size)
> +			return;
> +	}
>  
>  	low_base = memblock_find_in_range(low_size, (1ULL<<32),
>  					low_size, alignment);
>  
>  	if (!low_base) {
> -		pr_info("crashkernel low reservation failed - No suitable area found.\n");
> +		if (!auto_set)
> +			pr_info("crashkernel low reservation failed - No suitable area found.\n");
>  
>  		return;
>  	}
> Index: linux-2.6/include/linux/swiotlb.h
> ===================================================================
> --- linux-2.6.orig/include/linux/swiotlb.h
> +++ linux-2.6/include/linux/swiotlb.h
> @@ -25,6 +25,7 @@ extern int swiotlb_force;
>  extern void swiotlb_init(int verbose);
>  int swiotlb_init_with_tbl(char *tlb, unsigned long nslabs, int verbose);
>  extern unsigned long swiotlb_nr_tbl(void);
> +unsigned long swiotlb_size_or_default(void);
>  extern int swiotlb_late_init_with_tbl(char *tlb, unsigned long nslabs);
>  
>  /*
> Index: linux-2.6/lib/swiotlb.c
> ===================================================================
> --- linux-2.6.orig/lib/swiotlb.c
> +++ linux-2.6/lib/swiotlb.c
> @@ -105,9 +105,9 @@ setup_io_tlb_npages(char *str)
>  	if (!strcmp(str, "force"))
>  		swiotlb_force = 1;
>  
> -	return 1;
> +	return 0;
>  }
> -__setup("swiotlb=", setup_io_tlb_npages);
> +early_param("swiotlb", setup_io_tlb_npages);
>  /* make io_tlb_overflow tunable too? */
>  
>  unsigned long swiotlb_nr_tbl(void)
> @@ -115,6 +115,18 @@ unsigned long swiotlb_nr_tbl(void)
>  	return io_tlb_nslabs;
>  }
>  EXPORT_SYMBOL_GPL(swiotlb_nr_tbl);
> +
> +/* default to 64MB */
> +#define IO_TLB_DEFAULT_SIZE (64UL<<20)
> +unsigned long swiotlb_size_or_default(void)
> +{
> +	unsigned long size;
> +
> +	size = io_tlb_nslabs << IO_TLB_SHIFT;
> +
> +	return size ? size : (IO_TLB_DEFAULT_SIZE);
> +}
> +
>  /* Note that this doesn't work with highmem page */
>  static dma_addr_t swiotlb_virt_to_bus(struct device *hwdev,
>  				      volatile void *address)
> @@ -188,8 +200,7 @@ int __init swiotlb_init_with_tbl(char *t
>  void  __init
>  swiotlb_init(int verbose)
>  {
> -	/* default to 64MB */
> -	size_t default_size = 64UL<<20;
> +	size_t default_size = IO_TLB_DEFAULT_SIZE;
>  	unsigned char *vstart;
>  	unsigned long bytes;
>  
> Index: linux-2.6/Documentation/kernel-parameters.txt
> ===================================================================
> --- linux-2.6.orig/Documentation/kernel-parameters.txt
> +++ linux-2.6/Documentation/kernel-parameters.txt
> @@ -596,9 +596,6 @@ bytes respectively. Such letter suffixes
>  			is selected automatically. Check
>  			Documentation/kdump/kdump.txt for further details.
>  
> -	crashkernel_low=size[KMG]
> -			[KNL, x86] parts under 4G.
> -
>  	crashkernel=range1:size1[,range2:size2,...][@offset]
>  			[KNL] Same as above, but depends on the memory
>  			in the running system. The syntax of range is
> @@ -606,6 +603,17 @@ bytes respectively. Such letter suffixes
>  			a memory unit (amount[KMG]). See also
>  			Documentation/kdump/kdump.txt for an example.
>  
> +	crashkernel_low=size[KMG]
> +			[KNL, x86_64] range under 4G. When crashkernel= is
> +			passed, kernel allocate physical memory region
> +			above 4G, that cause second kernel crash on system
> +			that require some amount of low memory, e.g. swiotlb
> +			requires at least 64M+32K low memory.  Kernel would
> +			try to allocate 72M below 4G automatically.
> +			This one let user to specify own low range under 4G
> +			for second kernel instead.
> +			0: to disable low allocation.
> +
>  	cs89x0_dma=	[HW,NET]
>  			Format: <dma>
>  
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
> 


-- 
Thanks
Dave



^ permalink raw reply	[flat|nested] 20+ messages in thread

* Re: [PATCH v3 1/4] x86, kdump: Set crashkernel_low automatically
  2013-04-08  7:09   ` Dave Young
@ 2013-04-08 18:37     ` Yinghai Lu
  2013-04-09  3:25       ` Dave Young
  0 siblings, 1 reply; 20+ messages in thread
From: Yinghai Lu @ 2013-04-08 18:37 UTC (permalink / raw)
  To: Dave Young
  Cc: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, WANG Chao,
	Vivek Goyal, Eric W. Biederman, Linux Kernel Mailing List

On Mon, Apr 8, 2013 at 12:09 AM, Dave Young <dyoung@redhat.com> wrote:
>> We have now modified crashkernel=X to allocate memory beyong 4G (if
>> available) and do not allocate low range for crashkernel if the user
>> does not specify that with crashkernel_low=Y.  This causes regression
>> if iommu is not enabled.  Without iommu, swiotlb needs to be setup in
>> first 4G and there is no low memory available to second kernel.
>
> Is it possible to reuse the 1st kernel swiotlb region in 2nd capture
> kernel if it's available?

If the first kernel is using intel iommu, and swiotlb is freed after intel
iommus is enabled in first kernel.

>
>>
>> Set crashkernel_low automatically if the user does not specify that.
>>
>> For system that does support IOMMU with kdump properly, user could
>> specify crashkernel_low=0 to save that 72M low ram.
>
> How about make swiotlb size tunable in 1st kernel as well such as adding
> a swiotlb_size= to cmdline, if it's set in 1st kernel crashkernel
> reserving code can take it automaticlly.
>
can not understand this.

Thanks

Yinghai

^ permalink raw reply	[flat|nested] 20+ messages in thread

* Re: [PATCH v3 1/4] x86, kdump: Set crashkernel_low automatically
  2013-04-08 18:37     ` Yinghai Lu
@ 2013-04-09  3:25       ` Dave Young
  2013-04-09  3:37         ` Yinghai Lu
  0 siblings, 1 reply; 20+ messages in thread
From: Dave Young @ 2013-04-09  3:25 UTC (permalink / raw)
  To: Yinghai Lu
  Cc: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, WANG Chao,
	Vivek Goyal, Eric W. Biederman, Linux Kernel Mailing List

On 04/09/2013 02:37 AM, Yinghai Lu wrote:
> On Mon, Apr 8, 2013 at 12:09 AM, Dave Young <dyoung@redhat.com> wrote:
>>> We have now modified crashkernel=X to allocate memory beyong 4G (if
>>> available) and do not allocate low range for crashkernel if the user
>>> does not specify that with crashkernel_low=Y.  This causes regression
>>> if iommu is not enabled.  Without iommu, swiotlb needs to be setup in
>>> first 4G and there is no low memory available to second kernel.
>>
>> Is it possible to reuse the 1st kernel swiotlb region in 2nd capture
>> kernel if it's available?
> 
> If the first kernel is using intel iommu, and swiotlb is freed after intel
> iommus is enabled in first kernel.

Ok, also it's hard to handle such as 1st kernel iommu=off, 2nd kernel
iommu=on etc.

I have another question, under x86_64 consider 1st kernel memory < 4G,
is the swiotlb memory still necessary?

> 
>>
>>>
>>> Set crashkernel_low automatically if the user does not specify that.
>>>
>>> For system that does support IOMMU with kdump properly, user could
>>> specify crashkernel_low=0 to save that 72M low ram.
>>
>> How about make swiotlb size tunable in 1st kernel as well such as adding
>> a swiotlb_size= to cmdline, if it's set in 1st kernel crashkernel
>> reserving code can take it automaticlly.
>>
> can not understand this.

This maybe out of topic. I means swiotlb size is hardcoded, I'm thinking
how about make it configurable via kconfig or boot cmdline.

> 
> Thanks
> 
> Yinghai
> 


-- 
Thanks
Dave



^ permalink raw reply	[flat|nested] 20+ messages in thread

* Re: [PATCH v3 1/4] x86, kdump: Set crashkernel_low automatically
  2013-04-09  3:25       ` Dave Young
@ 2013-04-09  3:37         ` Yinghai Lu
  0 siblings, 0 replies; 20+ messages in thread
From: Yinghai Lu @ 2013-04-09  3:37 UTC (permalink / raw)
  To: Dave Young
  Cc: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, WANG Chao,
	Vivek Goyal, Eric W. Biederman, Linux Kernel Mailing List

On Mon, Apr 8, 2013 at 8:25 PM, Dave Young <dyoung@redhat.com> wrote:

> I have another question, under x86_64 consider 1st kernel memory < 4G,
> is the swiotlb memory still necessary?

No. unless use swiotlb=force.

Thanks

Yinghai

^ permalink raw reply	[flat|nested] 20+ messages in thread

* Re: [PATCH v3 3/4] x86, kdump: Change crashkernel_high/low= to crashkernel=;high/low
  2013-04-04 22:17 ` [PATCH v3 3/4] x86, kdump: Change crashkernel_high/low= to crashkernel=;high/low Yinghai Lu
@ 2013-04-09 13:45   ` Vivek Goyal
  2013-04-09 15:00     ` H. Peter Anvin
  2013-04-09 20:05     ` Yinghai Lu
  0 siblings, 2 replies; 20+ messages in thread
From: Vivek Goyal @ 2013-04-09 13:45 UTC (permalink / raw)
  To: Yinghai Lu
  Cc: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, WANG Chao,
	Eric W. Biederman, linux-kernel

On Thu, Apr 04, 2013 at 03:17:01PM -0700, Yinghai Lu wrote:

[..]
> @@ -1360,37 +1369,80 @@ static int __init parse_crashkernel_simp
>  
>  	if (*cur == '@')
>  		*crash_base = memparse(cur+1, &cur);
> -	else if (*cur != ' ' && *cur != '\0') {
> -		pr_warning("crashkernel: unrecognized char\n");
> -		return -EINVAL;
> +	else {
> +		int i;
> +
> +		/* check with known suffix */
> +		for (i = 0; suffix_tbl[i]; i++)
> +			if (!strncmp(cur, suffix_tbl[i], strlen(suffix_tbl[i])))
> +				return 0;
> +

So crashkernel=X@Y;high is a valid syntax? Looks like we will reserve
X amount of RAM at base Y and ignore "high" or "low".

[..]
>  static int __init __parse_crashkernel(char *cmdline,
>  			     unsigned long long system_ram,
>  			     unsigned long long *crash_size,
>  			     unsigned long long *crash_base,
> -				const char *name)
> +			     const char *name,
> +			     const char *suffix,
> +			     bool simple_only)
>  {
> -	char 	*p = cmdline, *ck_cmdline = NULL;
>  	char	*first_colon, *first_space;
> +	char	*ck_cmdline;
>  
>  	BUG_ON(!crash_size || !crash_base);
>  	*crash_size = 0;
>  	*crash_base = 0;
>  
> -	/* find crashkernel and use the last one if there are more */
> -	p = strstr(p, name);
> -	while (p) {
> -		ck_cmdline = p;
> -		p = strstr(p+1, name);
> -	}
> +	ck_cmdline = get_last_crashkernel(cmdline, name, suffix);
>  
>  	if (!ck_cmdline)
>  		return -EINVAL;
> @@ -1403,23 +1455,30 @@ static int __init __parse_crashkernel(ch
>  	 */
>  	first_colon = strchr(ck_cmdline, ':');
>  	first_space = strchr(ck_cmdline, ' ');
> -	if (first_colon && (!first_space || first_colon < first_space))
> -		return parse_crashkernel_mem(ck_cmdline, system_ram,
> -				crash_size, crash_base);
> -	else
> +	if (first_colon && (!first_space || first_colon < first_space)) {
> +		if (simple_only)
> +			return -EINVAL;
> +		else
> +			return parse_crashkernel_mem(ck_cmdline, system_ram,
> +					crash_size, crash_base);
> +	} else
>  		return parse_crashkernel_simple(ck_cmdline, crash_size,
>  				crash_base);

Why don't we structure it little differently. Now we seem to have 3 
categories of crashkernel= parameters.

- crashkernel_simple (crashkernel=X or crashkernel=X@Y)
- crashkernel_mem (crashkernel=range:size,.....)
- crashkerenl_high_low_suffix (crashkernel=X;high or crashkernel=Y;low)

if (suffix) {
	parse_crashkernel_high_low_suffix()
} else {
	if (first_colon.....)
		parse_crashkernel_mem()
	else
		parse_crashkernel_simple();
}

And now you should not require "simple_only" function parameter and you
can also do strict syntax checking for each type of crashkernel=
parameter.

Thanks
Vivek

^ permalink raw reply	[flat|nested] 20+ messages in thread

* Re: [PATCH v3 3/4] x86, kdump: Change crashkernel_high/low= to crashkernel=;high/low
  2013-04-09 13:45   ` Vivek Goyal
@ 2013-04-09 15:00     ` H. Peter Anvin
  2013-04-09 16:47       ` Vivek Goyal
  2013-04-09 20:05     ` Yinghai Lu
  1 sibling, 1 reply; 20+ messages in thread
From: H. Peter Anvin @ 2013-04-09 15:00 UTC (permalink / raw)
  To: Vivek Goyal, Yinghai Lu
  Cc: Thomas Gleixner, Ingo Molnar, WANG Chao, Eric W. Biederman, linux-kernel

Please, no semicolons. We already have established syntax for suboptions (option=suboption,suboption,...) and suboptions with parameters (option=suboption:value,...)

Vivek Goyal <vgoyal@redhat.com> wrote:

>On Thu, Apr 04, 2013 at 03:17:01PM -0700, Yinghai Lu wrote:
>
>[..]
>> @@ -1360,37 +1369,80 @@ static int __init parse_crashkernel_simp
>>  
>>  	if (*cur == '@')
>>  		*crash_base = memparse(cur+1, &cur);
>> -	else if (*cur != ' ' && *cur != '\0') {
>> -		pr_warning("crashkernel: unrecognized char\n");
>> -		return -EINVAL;
>> +	else {
>> +		int i;
>> +
>> +		/* check with known suffix */
>> +		for (i = 0; suffix_tbl[i]; i++)
>> +			if (!strncmp(cur, suffix_tbl[i], strlen(suffix_tbl[i])))
>> +				return 0;
>> +
>
>So crashkernel=X@Y;high is a valid syntax? Looks like we will reserve
>X amount of RAM at base Y and ignore "high" or "low".
>
>[..]
>>  static int __init __parse_crashkernel(char *cmdline,
>>  			     unsigned long long system_ram,
>>  			     unsigned long long *crash_size,
>>  			     unsigned long long *crash_base,
>> -				const char *name)
>> +			     const char *name,
>> +			     const char *suffix,
>> +			     bool simple_only)
>>  {
>> -	char 	*p = cmdline, *ck_cmdline = NULL;
>>  	char	*first_colon, *first_space;
>> +	char	*ck_cmdline;
>>  
>>  	BUG_ON(!crash_size || !crash_base);
>>  	*crash_size = 0;
>>  	*crash_base = 0;
>>  
>> -	/* find crashkernel and use the last one if there are more */
>> -	p = strstr(p, name);
>> -	while (p) {
>> -		ck_cmdline = p;
>> -		p = strstr(p+1, name);
>> -	}
>> +	ck_cmdline = get_last_crashkernel(cmdline, name, suffix);
>>  
>>  	if (!ck_cmdline)
>>  		return -EINVAL;
>> @@ -1403,23 +1455,30 @@ static int __init __parse_crashkernel(ch
>>  	 */
>>  	first_colon = strchr(ck_cmdline, ':');
>>  	first_space = strchr(ck_cmdline, ' ');
>> -	if (first_colon && (!first_space || first_colon < first_space))
>> -		return parse_crashkernel_mem(ck_cmdline, system_ram,
>> -				crash_size, crash_base);
>> -	else
>> +	if (first_colon && (!first_space || first_colon < first_space)) {
>> +		if (simple_only)
>> +			return -EINVAL;
>> +		else
>> +			return parse_crashkernel_mem(ck_cmdline, system_ram,
>> +					crash_size, crash_base);
>> +	} else
>>  		return parse_crashkernel_simple(ck_cmdline, crash_size,
>>  				crash_base);
>
>Why don't we structure it little differently. Now we seem to have 3 
>categories of crashkernel= parameters.
>
>- crashkernel_simple (crashkernel=X or crashkernel=X@Y)
>- crashkernel_mem (crashkernel=range:size,.....)
>- crashkerenl_high_low_suffix (crashkernel=X;high or crashkernel=Y;low)
>
>if (suffix) {
>	parse_crashkernel_high_low_suffix()
>} else {
>	if (first_colon.....)
>		parse_crashkernel_mem()
>	else
>		parse_crashkernel_simple();
>}
>
>And now you should not require "simple_only" function parameter and you
>can also do strict syntax checking for each type of crashkernel=
>parameter.
>
>Thanks
>Vivek

-- 
Sent from my mobile phone. Please excuse brevity and lack of formatting.

^ permalink raw reply	[flat|nested] 20+ messages in thread

* Re: [PATCH v3 3/4] x86, kdump: Change crashkernel_high/low= to crashkernel=;high/low
  2013-04-09 15:00     ` H. Peter Anvin
@ 2013-04-09 16:47       ` Vivek Goyal
  2013-04-09 16:49         ` H. Peter Anvin
  0 siblings, 1 reply; 20+ messages in thread
From: Vivek Goyal @ 2013-04-09 16:47 UTC (permalink / raw)
  To: H. Peter Anvin
  Cc: Yinghai Lu, Thomas Gleixner, Ingo Molnar, WANG Chao,
	Eric W. Biederman, linux-kernel

On Tue, Apr 09, 2013 at 08:00:57AM -0700, H. Peter Anvin wrote:
> Please, no semicolons. We already have established syntax for suboptions (option=suboption,suboption,...) and suboptions with parameters (option=suboption:value,...)

Ok, to understand it better, so crashkernel= will look as follows?

crashkernel=suboption[,suboption[,....]][@offset]

A suboption can be.

- A memory value (128[KMG])
- A range with value (range:size)
- Or a property influencing memory allocation behavior (e.g high or low)

If yes, sounds good.

Thanks
Vivek
 

> 
> Vivek Goyal <vgoyal@redhat.com> wrote:
> 
> >On Thu, Apr 04, 2013 at 03:17:01PM -0700, Yinghai Lu wrote:
> >
> >[..]
> >> @@ -1360,37 +1369,80 @@ static int __init parse_crashkernel_simp
> >>  
> >>  	if (*cur == '@')
> >>  		*crash_base = memparse(cur+1, &cur);
> >> -	else if (*cur != ' ' && *cur != '\0') {
> >> -		pr_warning("crashkernel: unrecognized char\n");
> >> -		return -EINVAL;
> >> +	else {
> >> +		int i;
> >> +
> >> +		/* check with known suffix */
> >> +		for (i = 0; suffix_tbl[i]; i++)
> >> +			if (!strncmp(cur, suffix_tbl[i], strlen(suffix_tbl[i])))
> >> +				return 0;
> >> +
> >
> >So crashkernel=X@Y;high is a valid syntax? Looks like we will reserve
> >X amount of RAM at base Y and ignore "high" or "low".
> >
> >[..]
> >>  static int __init __parse_crashkernel(char *cmdline,
> >>  			     unsigned long long system_ram,
> >>  			     unsigned long long *crash_size,
> >>  			     unsigned long long *crash_base,
> >> -				const char *name)
> >> +			     const char *name,
> >> +			     const char *suffix,
> >> +			     bool simple_only)
> >>  {
> >> -	char 	*p = cmdline, *ck_cmdline = NULL;
> >>  	char	*first_colon, *first_space;
> >> +	char	*ck_cmdline;
> >>  
> >>  	BUG_ON(!crash_size || !crash_base);
> >>  	*crash_size = 0;
> >>  	*crash_base = 0;
> >>  
> >> -	/* find crashkernel and use the last one if there are more */
> >> -	p = strstr(p, name);
> >> -	while (p) {
> >> -		ck_cmdline = p;
> >> -		p = strstr(p+1, name);
> >> -	}
> >> +	ck_cmdline = get_last_crashkernel(cmdline, name, suffix);
> >>  
> >>  	if (!ck_cmdline)
> >>  		return -EINVAL;
> >> @@ -1403,23 +1455,30 @@ static int __init __parse_crashkernel(ch
> >>  	 */
> >>  	first_colon = strchr(ck_cmdline, ':');
> >>  	first_space = strchr(ck_cmdline, ' ');
> >> -	if (first_colon && (!first_space || first_colon < first_space))
> >> -		return parse_crashkernel_mem(ck_cmdline, system_ram,
> >> -				crash_size, crash_base);
> >> -	else
> >> +	if (first_colon && (!first_space || first_colon < first_space)) {
> >> +		if (simple_only)
> >> +			return -EINVAL;
> >> +		else
> >> +			return parse_crashkernel_mem(ck_cmdline, system_ram,
> >> +					crash_size, crash_base);
> >> +	} else
> >>  		return parse_crashkernel_simple(ck_cmdline, crash_size,
> >>  				crash_base);
> >
> >Why don't we structure it little differently. Now we seem to have 3 
> >categories of crashkernel= parameters.
> >
> >- crashkernel_simple (crashkernel=X or crashkernel=X@Y)
> >- crashkernel_mem (crashkernel=range:size,.....)
> >- crashkerenl_high_low_suffix (crashkernel=X;high or crashkernel=Y;low)
> >
> >if (suffix) {
> >	parse_crashkernel_high_low_suffix()
> >} else {
> >	if (first_colon.....)
> >		parse_crashkernel_mem()
> >	else
> >		parse_crashkernel_simple();
> >}
> >
> >And now you should not require "simple_only" function parameter and you
> >can also do strict syntax checking for each type of crashkernel=
> >parameter.
> >
> >Thanks
> >Vivek
> 
> -- 
> Sent from my mobile phone. Please excuse brevity and lack of formatting.

^ permalink raw reply	[flat|nested] 20+ messages in thread

* Re: [PATCH v3 3/4] x86, kdump: Change crashkernel_high/low= to crashkernel=;high/low
  2013-04-09 16:47       ` Vivek Goyal
@ 2013-04-09 16:49         ` H. Peter Anvin
  2013-04-09 17:00           ` Vivek Goyal
  2013-04-09 17:12           ` Vivek Goyal
  0 siblings, 2 replies; 20+ messages in thread
From: H. Peter Anvin @ 2013-04-09 16:49 UTC (permalink / raw)
  To: Vivek Goyal
  Cc: Yinghai Lu, Thomas Gleixner, Ingo Molnar, WANG Chao,
	Eric W. Biederman, linux-kernel

On 04/09/2013 09:47 AM, Vivek Goyal wrote:
> On Tue, Apr 09, 2013 at 08:00:57AM -0700, H. Peter Anvin wrote:
>> Please, no semicolons. We already have established syntax for suboptions (option=suboption,suboption,...) and suboptions with parameters (option=suboption:value,...)
> 
> Ok, to understand it better, so crashkernel= will look as follows?
> 
> crashkernel=suboption[,suboption[,....]][@offset]
> 
> A suboption can be.
> 
> - A memory value (128[KMG])
> - A range with value (range:size)
> - Or a property influencing memory allocation behavior (e.g high or low)
> 
> If yes, sounds good.
> 

Sorry, I don't quite grok @offset and range:size here.

What exactly does those bits do?

	-hpa


-- 
H. Peter Anvin, Intel Open Source Technology Center
I work for Intel.  I don't speak on their behalf.


^ permalink raw reply	[flat|nested] 20+ messages in thread

* Re: [PATCH v3 3/4] x86, kdump: Change crashkernel_high/low= to crashkernel=;high/low
  2013-04-09 16:49         ` H. Peter Anvin
@ 2013-04-09 17:00           ` Vivek Goyal
  2013-04-09 17:12           ` Vivek Goyal
  1 sibling, 0 replies; 20+ messages in thread
From: Vivek Goyal @ 2013-04-09 17:00 UTC (permalink / raw)
  To: H. Peter Anvin
  Cc: Yinghai Lu, Thomas Gleixner, Ingo Molnar, WANG Chao,
	Eric W. Biederman, linux-kernel

On Tue, Apr 09, 2013 at 09:49:28AM -0700, H. Peter Anvin wrote:
> On 04/09/2013 09:47 AM, Vivek Goyal wrote:
> > On Tue, Apr 09, 2013 at 08:00:57AM -0700, H. Peter Anvin wrote:
> >> Please, no semicolons. We already have established syntax for suboptions (option=suboption,suboption,...) and suboptions with parameters (option=suboption:value,...)
> > 
> > Ok, to understand it better, so crashkernel= will look as follows?
> > 
> > crashkernel=suboption[,suboption[,....]][@offset]
> > 
> > A suboption can be.
> > 
> > - A memory value (128[KMG])
> > - A range with value (range:size)
> > - Or a property influencing memory allocation behavior (e.g high or low)
> > 
> > If yes, sounds good.
> > 
> 
> Sorry, I don't quite grok @offset and range:size here.
> 
> What exactly does those bits do?

We have following crashkernel= syntax defined in kernel-parameters.txt.

        crashkernel=range1:size1[,range2:size2,...][@offset]
                        [KNL] Same as above, but depends on the memory
                        in the running system. The syntax of range is
                        start-[end] where start and end are both
                        a memory unit (amount[KMG]). See also
                        Documentation/kdump/kdump.txt for an example.


Because memory required for filtering depended on existing RAM in the
box, somebody came with this syntax. "range" specifies the range of
memory present in the system and "value" represents how much RAM
to reserve if system RAM falls in the range.

For example (From kdump.txt)

crashkernel=512M-2G:64M,2G-:128M

This would mean:

    1) if the RAM is smaller than 512M, then don't reserve anything
       (this is the "rescue" case)
    2) if the RAM size is between 512M and 2G (exclusive), then reserve 64M
    3) if the RAM size is larger than 2G, then reserve 128M
 

Thanks
Vivek

^ permalink raw reply	[flat|nested] 20+ messages in thread

* Re: [PATCH v3 3/4] x86, kdump: Change crashkernel_high/low= to crashkernel=;high/low
  2013-04-09 16:49         ` H. Peter Anvin
  2013-04-09 17:00           ` Vivek Goyal
@ 2013-04-09 17:12           ` Vivek Goyal
  2013-04-09 17:20             ` H. Peter Anvin
  1 sibling, 1 reply; 20+ messages in thread
From: Vivek Goyal @ 2013-04-09 17:12 UTC (permalink / raw)
  To: H. Peter Anvin
  Cc: Yinghai Lu, Thomas Gleixner, Ingo Molnar, WANG Chao,
	Eric W. Biederman, linux-kernel

On Tue, Apr 09, 2013 at 09:49:28AM -0700, H. Peter Anvin wrote:
> On 04/09/2013 09:47 AM, Vivek Goyal wrote:
> > On Tue, Apr 09, 2013 at 08:00:57AM -0700, H. Peter Anvin wrote:
> >> Please, no semicolons. We already have established syntax for suboptions (option=suboption,suboption,...) and suboptions with parameters (option=suboption:value,...)
> > 
> > Ok, to understand it better, so crashkernel= will look as follows?
> > 
> > crashkernel=suboption[,suboption[,....]][@offset]
> > 
> > A suboption can be.
> > 
> > - A memory value (128[KMG])
> > - A range with value (range:size)
> > - Or a property influencing memory allocation behavior (e.g high or low)
> > 
> > If yes, sounds good.
> > 
> 
> Sorry, I don't quite grok @offset and range:size here.

And @offset means that reserve memory at a particular offset, if
available.

Thanks
Vivek

^ permalink raw reply	[flat|nested] 20+ messages in thread

* Re: [PATCH v3 3/4] x86, kdump: Change crashkernel_high/low= to crashkernel=;high/low
  2013-04-09 17:12           ` Vivek Goyal
@ 2013-04-09 17:20             ` H. Peter Anvin
  0 siblings, 0 replies; 20+ messages in thread
From: H. Peter Anvin @ 2013-04-09 17:20 UTC (permalink / raw)
  To: Vivek Goyal
  Cc: Yinghai Lu, Thomas Gleixner, Ingo Molnar, WANG Chao,
	Eric W. Biederman, linux-kernel

On 04/09/2013 10:12 AM, Vivek Goyal wrote:
> On Tue, Apr 09, 2013 at 09:49:28AM -0700, H. Peter Anvin wrote:
>> On 04/09/2013 09:47 AM, Vivek Goyal wrote:
>>> On Tue, Apr 09, 2013 at 08:00:57AM -0700, H. Peter Anvin wrote:
>>>> Please, no semicolons. We already have established syntax for suboptions (option=suboption,suboption,...) and suboptions with parameters (option=suboption:value,...)
>>>
>>> Ok, to understand it better, so crashkernel= will look as follows?
>>>
>>> crashkernel=suboption[,suboption[,....]][@offset]
>>>
>>> A suboption can be.
>>>
>>> - A memory value (128[KMG])
>>> - A range with value (range:size)
>>> - Or a property influencing memory allocation behavior (e.g high or low)
>>>
>>> If yes, sounds good.
>>>
>>
>> Sorry, I don't quite grok @offset and range:size here.
> 
> And @offset means that reserve memory at a particular offset, if
> available.
> 

OK, the @offset should probably be treated as a suboption, with an
implicit/optional comma.

Otherwise, makes sense to me.

	-hpa

-- 
H. Peter Anvin, Intel Open Source Technology Center
I work for Intel.  I don't speak on their behalf.


^ permalink raw reply	[flat|nested] 20+ messages in thread

* Re: [PATCH v3 3/4] x86, kdump: Change crashkernel_high/low= to crashkernel=;high/low
  2013-04-09 13:45   ` Vivek Goyal
  2013-04-09 15:00     ` H. Peter Anvin
@ 2013-04-09 20:05     ` Yinghai Lu
  2013-04-09 20:24       ` H. Peter Anvin
  1 sibling, 1 reply; 20+ messages in thread
From: Yinghai Lu @ 2013-04-09 20:05 UTC (permalink / raw)
  To: Vivek Goyal
  Cc: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, WANG Chao,
	Eric W. Biederman, Linux Kernel Mailing List

On Tue, Apr 9, 2013 at 6:45 AM, Vivek Goyal <vgoyal@redhat.com> wrote:
> On Thu, Apr 04, 2013 at 03:17:01PM -0700, Yinghai Lu wrote:
>
> [..]
>> @@ -1360,37 +1369,80 @@ static int __init parse_crashkernel_simp
>>
>>       if (*cur == '@')
>>               *crash_base = memparse(cur+1, &cur);
>> -     else if (*cur != ' ' && *cur != '\0') {
>> -             pr_warning("crashkernel: unrecognized char\n");
>> -             return -EINVAL;
>> +     else {
>> +             int i;
>> +
>> +             /* check with known suffix */
>> +             for (i = 0; suffix_tbl[i]; i++)
>> +                     if (!strncmp(cur, suffix_tbl[i], strlen(suffix_tbl[i])))
>> +                             return 0;
>> +
>
> So crashkernel=X@Y;high is a valid syntax? Looks like we will reserve
> X amount of RAM at base Y and ignore "high" or "low".

yes, we should reject them.

>
> [..]
...
>
> Why don't we structure it little differently. Now we seem to have 3
> categories of crashkernel= parameters.
>
> - crashkernel_simple (crashkernel=X or crashkernel=X@Y)
> - crashkernel_mem (crashkernel=range:size,.....)
> - crashkerenl_high_low_suffix (crashkernel=X;high or crashkernel=Y;low)
>
> if (suffix) {
>         parse_crashkernel_high_low_suffix()
> } else {
>         if (first_colon.....)
>                 parse_crashkernel_mem()
>         else
>                 parse_crashkernel_simple();
> }
>
> And now you should not require "simple_only" function parameter and you
> can also do strict syntax checking for each type of crashkernel=
> parameter.

yes, that will the code more readable.

Just send -v4 of this patch that will not reuse parse_crashkernel_simple.

Thanks

Yinghai

^ permalink raw reply	[flat|nested] 20+ messages in thread

* Re: [PATCH v3 3/4] x86, kdump: Change crashkernel_high/low= to crashkernel=;high/low
  2013-04-09 20:05     ` Yinghai Lu
@ 2013-04-09 20:24       ` H. Peter Anvin
  2013-04-09 20:29         ` Vivek Goyal
  0 siblings, 1 reply; 20+ messages in thread
From: H. Peter Anvin @ 2013-04-09 20:24 UTC (permalink / raw)
  To: Yinghai Lu
  Cc: Vivek Goyal, Thomas Gleixner, Ingo Molnar, WANG Chao,
	Eric W. Biederman, Linux Kernel Mailing List

On 04/09/2013 01:05 PM, Yinghai Lu wrote:
>>
>> So crashkernel=X@Y;high is a valid syntax? Looks like we will reserve
>> X amount of RAM at base Y and ignore "high" or "low".
> 
> yes, we should reject them.
> 

What if there isn't X amount of RAM available at base Y?

	-hpa


-- 
H. Peter Anvin, Intel Open Source Technology Center
I work for Intel.  I don't speak on their behalf.


^ permalink raw reply	[flat|nested] 20+ messages in thread

* Re: [PATCH v3 3/4] x86, kdump: Change crashkernel_high/low= to crashkernel=;high/low
  2013-04-09 20:24       ` H. Peter Anvin
@ 2013-04-09 20:29         ` Vivek Goyal
  2013-04-09 20:33           ` H. Peter Anvin
  0 siblings, 1 reply; 20+ messages in thread
From: Vivek Goyal @ 2013-04-09 20:29 UTC (permalink / raw)
  To: H. Peter Anvin
  Cc: Yinghai Lu, Thomas Gleixner, Ingo Molnar, WANG Chao,
	Eric W. Biederman, Linux Kernel Mailing List

On Tue, Apr 09, 2013 at 01:24:46PM -0700, H. Peter Anvin wrote:
> On 04/09/2013 01:05 PM, Yinghai Lu wrote:
> >>
> >> So crashkernel=X@Y;high is a valid syntax? Looks like we will reserve
> >> X amount of RAM at base Y and ignore "high" or "low".
> > 
> > yes, we should reject them.
> > 
> 
> What if there isn't X amount of RAM available at base Y?

We don't reserve anything.

In this context crashkernel=X@Y,high is invalid syntax and should probably
be ignored by parser. The very fact user specified the offset, high or
low option does not carry any meaning.

crashkernel=X,high is valid though.

Thanks
Vivek

^ permalink raw reply	[flat|nested] 20+ messages in thread

* Re: [PATCH v3 3/4] x86, kdump: Change crashkernel_high/low= to crashkernel=;high/low
  2013-04-09 20:29         ` Vivek Goyal
@ 2013-04-09 20:33           ` H. Peter Anvin
  0 siblings, 0 replies; 20+ messages in thread
From: H. Peter Anvin @ 2013-04-09 20:33 UTC (permalink / raw)
  To: Vivek Goyal
  Cc: Yinghai Lu, Thomas Gleixner, Ingo Molnar, WANG Chao,
	Eric W. Biederman, Linux Kernel Mailing List

On 04/09/2013 01:29 PM, Vivek Goyal wrote:
> On Tue, Apr 09, 2013 at 01:24:46PM -0700, H. Peter Anvin wrote:
>> On 04/09/2013 01:05 PM, Yinghai Lu wrote:
>>>>
>>>> So crashkernel=X@Y;high is a valid syntax? Looks like we will reserve
>>>> X amount of RAM at base Y and ignore "high" or "low".
>>>
>>> yes, we should reject them.
>>>
>>
>> What if there isn't X amount of RAM available at base Y?
> 
> We don't reserve anything.
> 
> In this context crashkernel=X@Y,high is invalid syntax and should probably
> be ignored by parser. The very fact user specified the offset, high or
> low option does not carry any meaning.
> 
> crashkernel=X,high is valid though.
> 

Yes, if the offset being invalid is an error, that is the right
behavior, I would think.

	-hpa


-- 
H. Peter Anvin, Intel Open Source Technology Center
I work for Intel.  I don't speak on their behalf.


^ permalink raw reply	[flat|nested] 20+ messages in thread

end of thread, other threads:[~2013-04-09 20:33 UTC | newest]

Thread overview: 20+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2013-04-04 22:16 [PATCH -v3 0/4] x86, kdump: Fix crashkernel high with old kexec-tools Yinghai Lu
2013-04-04 22:16 ` [PATCH v3 1/4] x86, kdump: Set crashkernel_low automatically Yinghai Lu
2013-04-08  7:09   ` Dave Young
2013-04-08 18:37     ` Yinghai Lu
2013-04-09  3:25       ` Dave Young
2013-04-09  3:37         ` Yinghai Lu
2013-04-04 22:16 ` [PATCH v3 4/4] kexec: use Crash kernel for Crash kernel low Yinghai Lu
2013-04-04 22:17 ` [PATCH v3 2/4] x86, kdump: Retore crashkernel= to allocate under 896M Yinghai Lu
2013-04-04 22:17 ` [PATCH v3 3/4] x86, kdump: Change crashkernel_high/low= to crashkernel=;high/low Yinghai Lu
2013-04-09 13:45   ` Vivek Goyal
2013-04-09 15:00     ` H. Peter Anvin
2013-04-09 16:47       ` Vivek Goyal
2013-04-09 16:49         ` H. Peter Anvin
2013-04-09 17:00           ` Vivek Goyal
2013-04-09 17:12           ` Vivek Goyal
2013-04-09 17:20             ` H. Peter Anvin
2013-04-09 20:05     ` Yinghai Lu
2013-04-09 20:24       ` H. Peter Anvin
2013-04-09 20:29         ` Vivek Goyal
2013-04-09 20:33           ` H. Peter Anvin

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).