WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

[Xen-devel] [patch] crashkernel allocation failure #2

To: Xen Development Mailing List <xen-devel@xxxxxxxxxxxxxxxxxxx>
Subject: [Xen-devel] [patch] crashkernel allocation failure #2
From: Gerd Hoffmann <kraxel@xxxxxxxxxx>
Date: Fri, 22 Jun 2007 11:46:07 +0200
Delivery-date: Mon, 25 Jun 2007 09:33:10 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Thunderbird 1.5.0.12 (X11/20070530)
   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
--- xen/arch/x86/setup.c.debug  2007-06-21 15:31:00.000000000 +0200
+++ xen/arch/x86/setup.c        2007-06-22 10:13:39.000000000 +0200
@@ -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++ )
     {
--- xen/common/page_alloc.c.debug       2007-06-21 15:31:00.000000000 +0200
+++ xen/common/page_alloc.c     2007-06-22 10:12:33.000000000 +0200
@@ -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
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
<Prev in Thread] Current Thread [Next in Thread>