Skip to contentSkip to conversation

pseries: phyp dump: reserve-release proof-of-concept

PATCH In review Manish Ahuja 4 participants 5 messages Jan 8, 2008 PowerPC

lore
Share & tools
lore

Manish Ahuja

author
#0 lore raw

PATCH 3/8 pseries: phyp dump: reserve-release proof-of-concept

Initial patch for reserving memory in early boot, and freeing it later. If the previous boot had ended with a crash, the reserved memory would contain a copy of the crashed kernel data.

Signed-off-by Manish Ahuja <[email protected]>
Signed-off-by Linas Vepstas <[email protected]>

----

 arch/powerpc/kernel/prom.c                 |   33 +++++++++++++
 arch/powerpc/platforms/pseries/Makefile    |    1 
 arch/powerpc/platforms/pseries/phyp_dump.c |   71 +++++++++++++++++++++++++++++
 include/asm-powerpc/phyp_dump.h            |   32 +++++++++++++
 4 files changed, 137 insertions(+)
include/asm-powerpc/phyp_dump.h new file +32 -0
Index: linux-2.6.24-rc2-git4/include/asm-powerpc/phyp_dump.h
===================================================================
@@ -0,0 +1,32 @@
+/*
+ * Hypervisor-assisted dump
+ *
+ * Linas Vepstas, Manish Ahuja 2007
+ * Copyright (c) 2007 IBM Corp.
+ *
+ *      This program is free software; you can redistribute it and/or
+ *      modify it under the terms of the GNU General Public License
+ *      as published by the Free Software Foundation; either version
+ *      2 of the License, or (at your option) any later version.
+ */
+
+#ifndef _PPC64_PHYP_DUMP_H
+#define _PPC64_PHYP_DUMP_H
+
+#ifdef CONFIG_PHYP_DUMP
+
+/* The RMR region will be saved for later dumping
+ * whenever the kernel crashes. Set this to 256MB. */
+#define PHYP_DUMP_RMR_START 0x0
+#define PHYP_DUMP_RMR_END   (1UL<<28)
+
+struct phyp_dump {
+	/* Memory that is reserved during very early boot. */
+	unsigned long init_reserve_start;
+	unsigned long init_reserve_size;
+};
+
+extern struct phyp_dump *phyp_dump_info;
+
+#endif /* CONFIG_PHYP_DUMP */
+#endif /* _PPC64_PHYP_DUMP_H */
arch/powerpc/platforms/pseries/phyp_dump.c new file +71 -0

71 lines not on this page · raw message

arch/powerpc/platforms/pseries/Makefile +1 -0
Index: linux-2.6.24-rc2-git4/arch/powerpc/platforms/pseries/Makefile
===================================================================
@@ -18,3 +18,4 @@ obj-$(CONFIG_HOTPLUG_CPU)	+= hotplug-cpu
 obj-$(CONFIG_HVC_CONSOLE)	+= hvconsole.o
 obj-$(CONFIG_HVCS)		+= hvcserver.o
 obj-$(CONFIG_HCALL_STATS)	+= hvCall_inst.o
+obj-$(CONFIG_PHYP_DUMP)	+= phyp_dump.o
arch/powerpc/kernel/prom.c +33 -0
Index: linux-2.6.24-rc2-git4/arch/powerpc/kernel/prom.c
===================================================================
@@ -51,6 +51,7 @@
 #include <asm/machdep.h>
 #include <asm/pSeries_reconfig.h>
 #include <asm/pci-bridge.h>
+#include <asm/phyp_dump.h>
 #include <asm/kexec.h>
 
 #ifdef DEBUG

@@ -1011,6 +1012,37 @@ static void __init early_reserve_mem(voi
 #endif
 }
 
+#ifdef CONFIG_PHYP_DUMP
+
+/**
+ * reserve_crashed_mem() - reserve all not-yet-dumped mmemory
+ *
+ * This routine will reserve almost all of the memory in the
+ * system, except for a few hundred megabytes used to boot the
+ * new kernel. As the reserved memory is dumped to the dump
+ * device (by userland tools), it will be freed and made available.
+ */
+static void __init reserve_crashed_mem(void)
+{
+	unsigned long crashed_base, crashed_size;
+
+	/* Reserve *everything* above the RMR. We'll free this real soon. */
+	crashed_base = PHYP_DUMP_RMR_END;
+	crashed_size = lmb_end_of_DRAM() - crashed_base;
+
+	/* XXX crashed_ram_end is wrong, since it may be beyond
+	 * the memory_limit, it will need to be adjusted. */
+	lmb_reserve(crashed_base, crashed_size);
+
+	phyp_dump_info->init_reserve_start = crashed_base;
+	phyp_dump_info->init_reserve_size = crashed_size;
+}
+
+#else
+static inline void __init reserve_crashed_mem(void) {}
+#endif /* CONFIG_PHYP_DUMP */
+
+
 void __init early_init_devtree(void *params)
 {
 	DBG(" -> early_init_devtree(%p)\n", params);

@@ -1043,6 +1075,7 @@ void __init early_init_devtree(void *par
 	reserve_kdump_trampoline();
 	reserve_crashkernel();
 	early_reserve_mem();
+	reserve_crashed_mem();
 
 	lmb_enforce_memory_limit(memory_limit);
 	lmb_analyze();
#1 lore raw
Quoted 6 lines · Manish Ahuja

Initial patch for reserving memory in early boot, and freeing it later. If the previous boot had ended with a crash, the reserved memory would contain a copy of the crashed kernel data.

Signed-off-by Manish Ahuja <[email protected]>
Signed-off-by Linas Vepstas <[email protected]>

I think the signed-off-by chain needs to be modified. The way it appears, you handled the patch first, then sent it to Linas, who forwarded it to whoever will take the patches from the list.

This obviously isn't true, since you are actually the one who is sending out the patches. Moreover, I believe that the [email protected] address is now dead, and shouldn't be used for this any more.

So, depending on which of you two wrote the majority of a patch, I think it should be either

| Signed-off-by: Manish Ahuja <[email protected]> | Acked-by: Linas Vepstas <[email protected]>

or

| From: Linas Vepstas <[email protected]>
| Signed-off-by: Manish Ahuja <[email protected]>

	Arnd <><
#2 lore raw
Quoted 6 lines · Arnd Bergmann
Quoted 4 lines · Manish Ahuja

Initial patch for reserving memory in early boot, and freeing it later. If the previous boot had ended with a crash, the reserved memory would contain a copy of the crashed kernel data.

Quoted 6 lines
Quoted 2 lines
Signed-off-by Manish Ahuja <[email protected]>
Signed-off-by Linas Vepstas <[email protected]>

I think the signed-off-by chain needs to be modified. The way it appears, you handled the patch first, then sent it to Linas, who forwarded it to whoever will take the patches from the list.

Well,
-- there was dual authorship. I remangled the patches while Manish wrote code & tested. And I'd mailed them out the first time around, so you could say I forwarded after heavy editing.

Quoted 3 lines

This obviously isn't true, since you are actually the one who is sending out the patches. Moreover, I believe that the [email protected] address is now dead, and shouldn't be used for this any more.

Hmm. I wanted to indicate that the work was done while I was at IBM; clearly, no one is going through git and changing old, expired email addrs, and so submission based on the old addr seemed appropriate.

I'm taking the Signed-off-by line as a quasi-legal thing: a fancy ID string, identifying the author(s), rather than a new way to manage email address books.

Quoted 2 lines

So, depending on which of you two wrote the majority of a patch, I think it should be either

I'm not sure there was a clear majority. I think Manish did more work in general, but we hacked this together side by side. I got him to create working tested code; I busted it up into individual, clean, documented, mailing-list ready chunks.

--linas

#3 lore raw
Quoted 18 lines · Linas Vepstas
Quoted 9 lines · Arnd Bergmann
Quoted 6 lines · Manish Ahuja

Initial patch for reserving memory in early boot, and freeing it later. If the previous boot had ended with a crash, the reserved memory would contain a copy of the crashed kernel data.

Signed-off-by Manish Ahuja <[email protected]>
Signed-off-by Linas Vepstas <[email protected]>
Quoted 7 lines

I think the signed-off-by chain needs to be modified. The way it appears, you handled the patch first, then sent it to Linas, who forwarded it to whoever will take the patches from the list.

This obviously isn't true, since you are actually the one who is sending out the patches. Moreover, I believe that the [email protected] address is now dead, and shouldn't be used for this any more.

Quoted 7 lines

Hmm. I wanted to indicate that the work was done while I was at IBM; clearly, no one is going through git and changing old, expired email addrs, and so submission based on the old addr seemed appropriate.

I'm taking the Signed-off-by line as a quasi-legal thing: a fancy ID string, identifying the author(s), rather than a new way to manage email address books.

No one's changing the git history (you can't), but it seems silly to submit a patch with an address that is already dead. There is a general expectation that if/when someone finds a bug in the code they can email the signed-off-by addresses and get a real person.

As far as indicating it was written at IBM, that should be covered by the copyright notices.

cheers

Signature · 8 lines
Michael Ellerman
OzLabs, IBM Australia Development Lab

wwweb: http://michael.ellerman.id.au
phone: +61 2 6212 1183 (tie line 70 21183)

We do not inherit the earth from our ancestors,
we borrow it from our children. - S.M.A.R.T Person
author
#4 lore raw
In reply to Arnd Bergmann

Arnd,

Sorry this patch ended up out of sequence. I reposted it properly again in the other thread.

We did talk about using gmail address, but Linas was more comfortable using this as this is where he was, when we did this. Hence the use of Austin address with gmail being on the cc list.

I am sure he will chime in with more details about it when he gets the opportunity.

Thanks,
Manish

Quoted 29 lines · Arnd Bergmann
Quoted 6 lines · Manish Ahuja

Initial patch for reserving memory in early boot, and freeing it later. If the previous boot had ended with a crash, the reserved memory would contain a copy of the crashed kernel data.

Signed-off-by Manish Ahuja <[email protected]>
Signed-off-by Linas Vepstas <[email protected]>

I think the signed-off-by chain needs to be modified. The way it appears, you handled the patch first, then sent it to Linas, who forwarded it to whoever will take the patches from the list.

This obviously isn't true, since you are actually the one who is sending out the patches. Moreover, I believe that the [email protected] address is now dead, and shouldn't be used for this any more.

So, depending on which of you two wrote the majority of a patch, I think it should be either

| Signed-off-by: Manish Ahuja <[email protected]> | Acked-by: Linas Vepstas <[email protected]>

or

| From: Linas Vepstas <[email protected]>
| Signed-off-by: Manish Ahuja <[email protected]>

	Arnd <><