linuxppc-dev.lists.ozlabs.org archive mirror
 help / color / mirror / Atom feed
From: Hari Bathini <hbathini@linux.ibm.com>
To: linuxppc-dev <linuxppc-dev@ozlabs.org>
Cc: Ananth N Mavinakayanahalli <ananth@linux.ibm.com>,
	Mahesh J Salgaonkar <mahesh@linux.ibm.com>,
	Vasant Hegde <hegdevasant@linux.ibm.com>,
	Oliver <oohall@gmail.com>, Nicholas Piggin <npiggin@gmail.com>,
	Stewart Smith <stewart@linux.ibm.com>,
	Daniel Axtens <dja@axtens.net>
Subject: [PATCH v4 16/25] powerpc/fadump: consider reserved ranges while reserving memory
Date: Tue, 16 Jul 2019 17:03:53 +0530	[thread overview]
Message-ID: <156327683333.27462.16508019226700071.stgit@hbathini.in.ibm.com> (raw)
In-Reply-To: <156327668777.27462.5297279227799429100.stgit@hbathini.in.ibm.com>

Commit 0962e8004e97 ("powerpc/prom: Scan reserved-ranges node for
memory reservations") enabled support to parse reserved-ranges DT
node and reserve kernel memory falling in these ranges for F/W
purposes. Ensure memory in these ranges is not overlapped with
memory reserved for FADump.

Also, use a smaller offset, instead of the size of the memory to
be reserved, by which to skip memory before making another attempt
at reserving memory, after the previous attempt to reserve memory
for FADump failed due to memory holes and/or reserved ranges, to
reduce the likelihood of memory reservation failure.

Signed-off-by: Hari Bathini <hbathini@linux.ibm.com>
---
 arch/powerpc/kernel/fadump-common.h |   13 +++
 arch/powerpc/kernel/fadump.c        |  143 ++++++++++++++++++++++++++++++++++-
 2 files changed, 149 insertions(+), 7 deletions(-)

diff --git a/arch/powerpc/kernel/fadump-common.h b/arch/powerpc/kernel/fadump-common.h
index 06d9ecf..968745a 100644
--- a/arch/powerpc/kernel/fadump-common.h
+++ b/arch/powerpc/kernel/fadump-common.h
@@ -86,7 +86,7 @@ struct fadump_crash_info_header {
 	struct cpumask	online_mask;
 };
 
-struct fad_crash_memory_ranges {
+struct fadump_memory_range {
 	unsigned long long	base;
 	unsigned long long	size;
 };
@@ -94,6 +94,17 @@ struct fad_crash_memory_ranges {
 /* Platform specific callback functions */
 struct fadump_ops;
 
+/*
+ * Amount of memory (1024MB) to skip before making another attempt at
+ * reserving memory (after the previous attempt to reserve memory for
+ * FADump failed due to memory holes and/or reserved ranges) to reduce
+ * the likelihood of memory reservation failure.
+ */
+#define FADUMP_OFFSET_SIZE			0x40000000U
+
+/* Maximum no. of reserved ranges supported for processing. */
+#define FADUMP_MAX_RESERVED_RANGES		128
+
 /* Maximum number of memory regions kernel supports */
 #define FADUMP_MAX_MEM_REGS			128
 
diff --git a/arch/powerpc/kernel/fadump.c b/arch/powerpc/kernel/fadump.c
index abf4f334..bface37 100644
--- a/arch/powerpc/kernel/fadump.c
+++ b/arch/powerpc/kernel/fadump.c
@@ -36,11 +36,14 @@
 static struct fw_dump fw_dump;
 
 static DEFINE_MUTEX(fadump_mutex);
-struct fad_crash_memory_ranges *crash_memory_ranges;
+struct fadump_memory_range *crash_memory_ranges;
 int crash_memory_ranges_size;
 int crash_mem_ranges;
 int max_crash_mem_ranges;
 
+struct fadump_memory_range reserved_ranges[FADUMP_MAX_RESERVED_RANGES];
+int reserved_ranges_cnt;
+
 #ifdef CONFIG_CMA
 static struct cma *fadump_cma;
 
@@ -104,12 +107,116 @@ int __init fadump_cma_init(void)
 static int __init fadump_cma_init(void) { return 1; }
 #endif /* CONFIG_CMA */
 
+/*
+ * Sort the reserved ranges in-place and merge adjacent ranges
+ * to minimize the reserved ranges count.
+ */
+static void __init sort_and_merge_reserved_ranges(void)
+{
+	unsigned long long base, size;
+	struct fadump_memory_range tmp_range;
+	int i, j, idx;
+
+	if (!reserved_ranges_cnt)
+		return;
+
+	/* Sort the reserved ranges */
+	for (i = 0; i < reserved_ranges_cnt; i++) {
+		idx = i;
+		for (j = i + 1; j < reserved_ranges_cnt; j++) {
+			if (reserved_ranges[idx].base > reserved_ranges[j].base)
+				idx = j;
+		}
+		if (idx != i) {
+			tmp_range = reserved_ranges[idx];
+			reserved_ranges[idx] = reserved_ranges[i];
+			reserved_ranges[i] = tmp_range;
+		}
+	}
+
+	/* Merge adjacent reserved ranges */
+	idx = 0;
+	for (i = 1; i < reserved_ranges_cnt; i++) {
+		base = reserved_ranges[i-1].base;
+		size = reserved_ranges[i-1].size;
+		if (reserved_ranges[i].base == (base + size))
+			reserved_ranges[idx].size += reserved_ranges[i].size;
+		else {
+			idx++;
+			if (i == idx)
+				continue;
+
+			reserved_ranges[idx] = reserved_ranges[i];
+		}
+	}
+	reserved_ranges_cnt = idx + 1;
+}
+
+static int __init add_reserved_range(unsigned long base,
+				     unsigned long size)
+{
+	int i;
+
+	if (reserved_ranges_cnt == FADUMP_MAX_RESERVED_RANGES) {
+		/* Compact reserved ranges and try again. */
+		sort_and_merge_reserved_ranges();
+		if (reserved_ranges_cnt == FADUMP_MAX_RESERVED_RANGES)
+			return 0;
+	}
+
+	i = reserved_ranges_cnt++;
+	reserved_ranges[i].base = base;
+	reserved_ranges[i].size = size;
+	return 1;
+}
+
+/*
+ * Scan reserved-ranges to consider them while reserving/releasing
+ * memory for FADump.
+ */
+static void __init early_init_dt_scan_reserved_ranges(unsigned long node)
+{
+	int len, ret;
+	unsigned long i;
+	const __be32 *prop;
+
+	/* reserved-ranges already scanned */
+	if (reserved_ranges_cnt != 0)
+		return;
+
+	prop = of_get_flat_dt_prop(node, "reserved-ranges", &len);
+
+	if (!prop)
+		return;
+
+	/*
+	 * Each reserved range is an (address,size) pair, 2 cells each,
+	 * totalling 4 cells per range.
+	 */
+	for (i = 0; i < len / (sizeof(*prop) * 4); i++) {
+		u64 base, size;
+
+		base = of_read_number(prop + (i * 4) + 0, 2);
+		size = of_read_number(prop + (i * 4) + 2, 2);
+
+		if (size) {
+			ret = add_reserved_range(base, size);
+			if (ret == 0)
+				pr_warn("some reserved ranges are ignored!\n");
+		}
+	}
+}
+
 /* Scan the Firmware Assisted dump configuration details. */
 int __init early_init_dt_scan_fw_dump(unsigned long node, const char *uname,
 				      int depth, void *data)
 {
-	if (depth != 1)
+	if (depth != 1) {
+		if (depth == 0)
+			early_init_dt_scan_reserved_ranges(node);
+
 		return 0;
+	}
 
 	if (strcmp(uname, "rtas") == 0)
 		return rtas_fadump_dt_scan(&fw_dump, node);
@@ -355,6 +462,26 @@ static int __init fadump_get_boot_mem_regions(void)
 	return ret;
 }
 
+static bool overlaps_with_reserved_ranges(ulong base, ulong end)
+{
+	int i, ret = 0;
+
+	for (i = 0; i < reserved_ranges_cnt; i++) {
+		ulong rbase = (ulong)reserved_ranges[i].base;
+		ulong rend = rbase + (ulong)reserved_ranges[i].size;
+
+		if (end <= rbase)
+			break;
+
+		if ((end > rbase) &&  (base < rend)) {
+			ret = 1;
+			break;
+		}
+	}
+
+	return ret;
+}
+
 static void __init fadump_reserve_crash_area(unsigned long base,
 					     unsigned long size)
 {
@@ -388,6 +515,9 @@ int __init fadump_reserve_mem(void)
 		goto error_out;
 	}
 
+	/* Compact reserved ranges */
+	sort_and_merge_reserved_ranges();
+
 	/*
 	 * Initialize boot memory size
 	 * If dump is active then we have already calculated the size during
@@ -447,10 +577,11 @@ int __init fadump_reserve_mem(void)
 		 */
 		while (base <= (memory_boundary - size)) {
 			if (memblock_is_region_memory(base, size) &&
-			    !memblock_is_region_reserved(base, size))
+			    !memblock_is_region_reserved(base, size) &&
+			    !overlaps_with_reserved_ranges(base, (base+size)))
 				break;
 
-			base += size;
+			base += FADUMP_OFFSET_SIZE;
 		}
 
 		if (base > (memory_boundary - size)) {
@@ -579,7 +710,7 @@ static void free_crash_memory_ranges(void)
  */
 static int allocate_crash_memory_ranges(void)
 {
-	struct fad_crash_memory_ranges *new_array;
+	struct fadump_memory_range *new_array;
 	u64 new_size;
 
 	new_size = crash_memory_ranges_size + PAGE_SIZE;
@@ -596,7 +727,7 @@ static int allocate_crash_memory_ranges(void)
 	crash_memory_ranges = new_array;
 	crash_memory_ranges_size = new_size;
 	max_crash_mem_ranges = (new_size /
-				sizeof(struct fad_crash_memory_ranges));
+				sizeof(struct fadump_memory_range));
 	return 0;
 }
 


  parent reply	other threads:[~2019-07-16 12:04 UTC|newest]

Thread overview: 47+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-07-16 11:31 [PATCH v4 00/25] Add FADump support on PowerNV platform Hari Bathini
2019-07-16 11:32 ` [PATCH v4 01/25] powerpc/fadump: move internal macros/definitions to a new header Hari Bathini
2019-07-16 11:32 ` [PATCH v4 02/25] powerpc/fadump: move internal code to a new file Hari Bathini
2019-07-16 11:32 ` [PATCH v4 03/25] powerpc/fadump: Improve fadump documentation Hari Bathini
2019-08-12  6:55   ` Mahesh Jagannath Salgaonkar
2019-07-16 11:32 ` [PATCH v4 04/25] pseries/fadump: move rtas specific definitions to platform code Hari Bathini
2019-07-16 11:32 ` [PATCH v4 05/25] pseries/fadump: introduce callbacks for platform specific operations Hari Bathini
2019-08-12  9:42   ` Mahesh J Salgaonkar
2019-08-14  6:39     ` Hari Bathini
2019-07-16 11:32 ` [PATCH v4 06/25] pseries/fadump: define register/un-register callback functions Hari Bathini
2019-08-12 16:01   ` Mahesh J Salgaonkar
2019-08-14  6:41     ` Hari Bathini
2019-07-16 11:32 ` [PATCH v4 07/25] pseries/fadump: move out platform specific support from generic code Hari Bathini
2019-08-13  5:16   ` Mahesh J Salgaonkar
2019-07-16 11:32 ` [PATCH v4 08/25] powerpc/fadump: use FADump instead of fadump for how it is pronounced Hari Bathini
2019-07-16 11:33 ` [PATCH v4 09/25] opal: add MPIPL interface definitions Hari Bathini
2019-07-16 11:33 ` [PATCH v4 10/25] powernv/fadump: add fadump support on powernv Hari Bathini
2019-07-16 11:33 ` [PATCH v4 11/25] powernv/fadump: register kernel metadata address with opal Hari Bathini
2019-08-13 10:41   ` Mahesh J Salgaonkar
2019-08-14  7:06     ` Hari Bathini
2019-08-14 10:21       ` Mahesh Jagannath Salgaonkar
2019-08-19 15:49         ` Hari Bathini
2019-07-16 11:33 ` [PATCH v4 12/25] powernv/fadump: define register/un-register callback functions Hari Bathini
2019-08-13 14:34   ` Mahesh J Salgaonkar
2019-08-14  7:11     ` Hari Bathini
2019-07-16 11:33 ` [PATCH v4 13/25] powernv/fadump: support copying multiple kernel memory regions Hari Bathini
2019-08-13 15:03   ` Mahesh J Salgaonkar
2019-08-14  7:14     ` Hari Bathini
2019-07-16 11:33 ` [PATCH v4 14/25] powernv/fadump: process the crashdump by exporting it as /proc/vmcore Hari Bathini
2019-08-14 10:18   ` Mahesh J Salgaonkar
2019-08-14 11:11     ` Hari Bathini
2019-07-16 11:33 ` [PATCH v4 15/25] powerpc/fadump: Update documentation about OPAL platform support Hari Bathini
2019-07-16 11:33 ` Hari Bathini [this message]
2019-07-16 11:34 ` [PATCH v4 17/25] powerpc/fadump: consider reserved ranges while releasing memory Hari Bathini
2019-07-16 11:34 ` [PATCH v4 18/25] powernv/fadump: process architected register state data provided by firmware Hari Bathini
2019-08-14 17:15   ` Mahesh J Salgaonkar
2019-08-16  2:38     ` Hari Bathini
2019-07-16 11:34 ` [PATCH v4 19/25] powernv/fadump: add support to preserve crash data on FADUMP disabled kernel Hari Bathini
2019-08-16  5:01   ` Mahesh J Salgaonkar
2019-07-16 11:34 ` [PATCH v4 20/25] powerpc/fadump: update documentation about CONFIG_PRESERVE_FA_DUMP Hari Bathini
2019-07-16 11:34 ` [PATCH v4 21/25] powernv/opalcore: export /sys/firmware/opal/core for analysing opal crashes Hari Bathini
2019-07-16 11:34 ` [PATCH v4 22/25] powernv/fadump: Warn before processing partial crashdump Hari Bathini
2019-08-16  5:59   ` Mahesh J Salgaonkar
2019-07-16 11:34 ` [PATCH v4 23/25] powernv/opalcore: provide an option to invalidate /sys/firmware/opal/core file Hari Bathini
2019-07-16 11:34 ` [PATCH v4 24/25] powernv/fadump: consider f/w load area Hari Bathini
2019-07-16 11:35 ` [PATCH v4 25/25] powernv/fadump: update documentation about option to release opalcore Hari Bathini
2019-07-19  6:19 ` [PATCH v4 00/25] Add FADump support on PowerNV platform Hari Bathini

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=156327683333.27462.16508019226700071.stgit@hbathini.in.ibm.com \
    --to=hbathini@linux.ibm.com \
    --cc=ananth@linux.ibm.com \
    --cc=dja@axtens.net \
    --cc=hegdevasant@linux.ibm.com \
    --cc=linuxppc-dev@ozlabs.org \
    --cc=mahesh@linux.ibm.com \
    --cc=npiggin@gmail.com \
    --cc=oohall@gmail.com \
    --cc=stewart@linux.ibm.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;
as well as URLs for NNTP newsgroup(s).