Skip to contentSkip to conversation

crashkernel allocation failure #2

PATCH In review Gerd Hoffmann 2 participants 3 messages Jun 22, 2007 – Jun 26, 2007 x86

lore
Share & tools
lore
#0 lore raw

PATCH 1/1 crashkernel allocation failure #2

Hi,

Reserving the crashkernel area fails on x86_64 machines with more than one GB of main memory. The reason for this is that xen maps the complete physical memory. For memory above 1G (which is covered by the initial boot mappings) additional page tables are allocated, which happed to be taken from the crashkernel area. Bummer.

The attached patch fixes that by taking care that the boot allocater doesn't give out pages from the crash kernel area. It does also take care that the crash kernel area doesn't overlap with the xen heap and moves crash kernel area it if needed.

A side effect of the second change is that you can specify just "crashkernel=64m" and have it moved to the right place just above the xen heap automagically.

please apply,

Gerd

arch/x86/setup.c renamed from arch/x86/setup.c.debug +5 -0
@@ -460,6 +460,11 @@
 
     /* Initialise boot-time allocator with all RAM situated after modules. */
     xenheap_phys_start = init_boot_allocator(__pa(&_end));
+    if (kexec_crash_area.size > 0 && kexec_crash_area.start < xenheap_phys_end) {
+	printk("Moving crashkernel start: %ldm -> %ldm\n",
+	       kexec_crash_area.start >> 20, xenheap_phys_end >> 20);
+	kexec_crash_area.start = xenheap_phys_end;
+    }
     nr_pages = 0;
     for ( i = 0; i < e820.nr_map; i++ )
     {
common/page_alloc.c renamed from common/page_alloc.c.debug +9 -1
@@ -36,6 +36,7 @@
 #include <xen/perfc.h>
 #include <xen/numa.h>
 #include <xen/nodemask.h>
+#include <xen/kexec.h>
 #include <asm/page.h>
 
 /*
@@ -262,9 +263,16 @@
     unsigned long nr_pfns, unsigned long pfn_align)
 {
     unsigned long pg, i;
+    unsigned long start_mfn = first_valid_mfn;
+    unsigned long kexec_end = \
+	(kexec_crash_area.start + kexec_crash_area.size) >> PAGE_SHIFT;
+
+    /* make sure we don't give out pages from the crashkernel area */
+    if (start_mfn < kexec_end)
+	start_mfn = kexec_end;
 
     /* Search forwards to obtain lowest available range. */
-    for ( pg = first_valid_mfn & ~(pfn_align - 1);
+    for ( pg = start_mfn & ~(pfn_align - 1);
           (pg + nr_pfns) <= max_page;
           pg = (pg + i + pfn_align) & ~(pfn_align - 1) )
     {

_______________________________________________
Xen-devel mailing list
[email protected]
http://lists.xensource.com/xen-devel

#1 lore raw
Quoted 3 lines · Gerd Hoffmann

A side effect of the second change is that you can specify just "crashkernel=64m" and have it moved to the right place just above the xen heap automagically.

Does this really work in practice (i.e., is the crashkernel relocatable)?

-- Keir

#2 lore raw
Quoted 7 lines · Keir Fraser
Quoted 3 lines · Gerd Hoffmann

A side effect of the second change is that you can specify just "crashkernel=64m" and have it moved to the right place just above the xen heap automagically.

Does this really work in practice (i.e., is the crashkernel relocatable)?

Patches floating around for quite some time, i386 is mainline already. Not fully sure about x86_64, but I think it they are merged too. So any recent mainline kernel as crash kernel should do (and a separate crash kernel isn't needed too).

Also with the default xenheap size the crashkernel ends up at @16m, which is a common location for pre-relocation crash kernels, so it should work with older kernels just fine too. Of course you still have the option to explicitly specify the location ...

cheers,
Gerd