[PATCH] [powerpc] Export memory limit via device tree

The powerpc kernel doesn't export the memory limit enforced by 'mem='
kernel parameter. This is required for building the ELF header in
kexec-tools to limit the vmcore to capture only the used memory. On
powerpc the kexec-tools depends on the device-tree for memory related
information, unlike /proc/iomem on the x86.

Without this information, the kexec-tools assumes the entire System
RAM and vmcore creates an unnecessarily larger dump.

This patch exports the memory limit, if present, via chosen/linux,memory-limit
property, so that the vmcore can be limited to the memory limit.

The prom_init seems to export this value in the same node. But doesn't really
appear there.  Also the memory_limit gets adjusted with the processing of
crashkernel= parameter. This patch makes sure we get the actual limit.

The kexec-tools will use the value to limit the 'end' of the memory
regions.

Tested this patch on ppc64 and ppc32(ppc440) with a kexec-tools
patch by Mahesh.

Signed-off-by: Suzuki K. Poulose <redacted>
Tested-by: Mahesh J. Salgaonkar <redacted>
---

 arch/powerpc/kernel/machine_kexec.c |   15 +++++++++++++++
 1 files changed, 15 insertions(+), 0 deletions(-)

diff --git a/arch/powerpc/kernel/machine_kexec.c b/arch/powerpc/kernel/machine_kexec.c
index c957b12..0c9695d 100644
--- a/arch/powerpc/kernel/machine_kexec.c
+++ b/arch/powerpc/kernel/machine_kexec.c

@@ -207,6 +207,12 @@ static struct property crashk_size_prop = {
 	.value = &crashk_size,
 };
 
+static struct property memory_limit_prop = {
+	.name = "linux,memory-limit",
+	.length = sizeof(phys_addr_t),
+	.value = &memory_limit,
+};
+
 static void __init export_crashk_values(struct device_node *node)
 {
 	struct property *prop;

@@ -226,6 +232,15 @@ static void __init export_crashk_values(struct device_node *node)
 		crashk_size = resource_size(&crashk_res);
 		prom_add_property(node, &crashk_size_prop);
 	}
+
+	/* memory-limit is needed for constructing the crash regions */
+	prop = of_find_property(node, memory_limit_prop.name, NULL);
+	if (prop)
+		prom_remove_property(node, prop);
+
+	if (memory_limit)
+		prom_add_property(node, &memory_limit_prop);
+
 }
 
 static int __init kexec_setup(void)

AFAIK. phys_addr_t can change size, so instead make it point to a known
fixes size quantity (a u64).

+
+	/* memory-limit is needed for constructing the crash regions */
+	prop = of_find_property(node, memory_limit_prop.name, NULL);
+	if (prop)
+		prom_remove_property(node, prop);
+
+	if (memory_limit)
+		prom_add_property(node, &memory_limit_prop);
+

There's a patch floating around making prom_update_property properly
handle both pre-existing and non-pre-existing props, you should probably
base yourself on top of it. I'm about to stick that patch in powerpc
-next

Cheers,
Ben.

On 07/11/2012 11:06 AM, Benjamin Herrenschmidt wrote:

quoted

diff --git a/arch/powerpc/kernel/machine_kexec.c b/arch/powerpc/kernel/machine_kexec.c
index c957b12..0c9695d 100644
--- a/arch/powerpc/kernel/machine_kexec.c
+++ b/arch/powerpc/kernel/machine_kexec.c

@@ -207,6 +207,12 @@ static struct property crashk_size_prop = {
  	.value = &crashk_size,
  };

+static struct property memory_limit_prop = {
+	.name = "linux,memory-limit",
+	.length = sizeof(phys_addr_t),
+	.value = &memory_limit,
+};
+

AFAIK. phys_addr_t can change size, so instead make it point to a known
fixes size quantity (a u64).

Ben,

Sorry for the delay in the response.

Some of the other properties are also of phys_addr_t, (e.g 
linux,crashkernel-base, linux,kernel-end ). Should we fix them as well ?

Or

Should we leave this also a phys_addr_t and let the userspace handle it ?

quoted

+
+	/* memory-limit is needed for constructing the crash regions */
+	prop = of_find_property(node, memory_limit_prop.name, NULL);
+	if (prop)
+		prom_remove_property(node, prop);
+
+	if (memory_limit)
+		prom_add_property(node, &memory_limit_prop);
+

There's a patch floating around making prom_update_property properly
handle both pre-existing and non-pre-existing props, you should probably
base yourself on top of it. I'm about to stick that patch in powerpc
-next

OK. I am testing the new patch based on the above commit. I will wait
for the clarification on the issue of the type, before I post it here.

Thanks
Suzuki