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-ia64-devel

Re: [Xen-ia64-devel] [PATCH 4/5] kexec: fix /proc/iomem_machine

To: Isaku Yamahata <yamahata@xxxxxxxxxxxxx>
Subject: Re: [Xen-ia64-devel] [PATCH 4/5] kexec: fix /proc/iomem_machine
From: Simon Horman <horms@xxxxxxxxxxxx>
Date: Thu, 24 Jul 2008 19:55:48 +1000
Cc: xen-ia64-devel@xxxxxxxxxxxxxxxxxxx
Delivery-date: Thu, 24 Jul 2008 02:55:54 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <20080724081549.GG28251%yamahata@xxxxxxxxxxxxx>
List-help: <mailto:xen-ia64-devel-request@lists.xensource.com?subject=help>
List-id: Discussion of the ia64 port of Xen <xen-ia64-devel.lists.xensource.com>
List-post: <mailto:xen-ia64-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/mailman/listinfo/xen-ia64-devel>, <mailto:xen-ia64-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-ia64-devel>, <mailto:xen-ia64-devel-request@lists.xensource.com?subject=unsubscribe>
References: <20080724055959.GA14460@xxxxxxxxxxxxxxxxxxxxxxxxxx> <20080724080417.GE8421@xxxxxxxxxxxx> <20080724081549.GG28251%yamahata@xxxxxxxxxxxxx>
Sender: xen-ia64-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Mutt/1.5.18 (2008-05-17)
On Thu, Jul 24, 2008 at 05:15:49PM +0900, Isaku Yamahata wrote:
> On Thu, Jul 24, 2008 at 06:04:19PM +1000, Simon Horman wrote:
> > On Thu, Jul 24, 2008 at 02:59:59PM +0900, Isaku Yamahata wrote:
> > > [IA64] initialize /proc/iomem_machine properly when discontig mem.
> > > 
> > > With CONFIG_DISCONTIGMEM enabled /proc/iomem_machine isn't
> > > initialized properly so that kexec failes because kexec-tools wrongly
> > > tries to use ia64 boot mem (or efi memmap area).
> > > This patch fixes /proc/iomem_machine.
> > > 
> > > Signed-off-by: Isaku Yamahata <yamahata@xxxxxxxxxxxxx>
> > > 
> > > diff -r 75235538851a arch/ia64/mm/discontig.c
> > > --- a/arch/ia64/mm/discontig.c    Thu Jul 24 14:31:08 2008 +0900
> > > +++ b/arch/ia64/mm/discontig.c    Thu Jul 24 14:31:27 2008 +0900
> > > @@ -21,6 +21,9 @@
> > >  #include <linux/acpi.h>
> > >  #include <linux/efi.h>
> > >  #include <linux/nodemask.h>
> > > +#if defined(CONFIG_XEN) && defined(CONFIG_KEXEC)
> > > +#include <linux/kexec.h>
> > > +#endif
> > >  #include <asm/pgalloc.h>
> > >  #include <asm/tlb.h>
> > >  #include <asm/meminit.h>
> > > @@ -502,10 +505,18 @@
> > >   reserve_pernode_space();
> > >   memory_less_nodes();
> > >   initialize_pernode_data();
> > > +#if defined(CONFIG_XEN) && defined(CONFIG_KEXEC)
> > > + xen_machine_kexec_setup_resources();
> > > +#endif
> > >  
> > >   max_pfn = max_low_pfn;
> > >  
> > >   find_initrd();
> > > +#ifdef CONFIG_CRASH_DUMP
> > > + /* If we are doing a crash dump, we still need to know the real mem
> > > +  * size before original memory map is * reset. */
> > > + saved_max_pfn = max_pfn;
> > > +#endif
> > >  }
> > >  
> > >  #ifdef CONFIG_SMP
> > 
> > I need to review this more fully, but should #ifdef CONFIG_CRASH_DUMP
> > be #ifdef CONFIG_KEXEC?
> 
> To be honest, I'm not sure with saved_max_pfn.
> I just followed find_memory() in linux/arch/ia64/mm/contig.c
> which is commited by changeset:   229:d3f72c686185.
> Upstream Linux changeset 45a98fc622ae700eed34eb2be00743910d50dbe1

I think that saved_max_pfn isn't entirely related to the problem that
you are seeing. On Linux it is used in the second kernel after
crash dump to deterimin the size of /proc/vmcore - that is to make
it match the physical memory rather than the limited memory that
the crash dump kernel runs in.

As a crash dump kernel currently can't be a dom0 (or domU) kernel,
I don't think that it is that important in the context of linux-xen.
We could probably even eliminate it, but it seems better to leave it
rather than add diferences to upstram linux.

Also, while looking into your change I came across
f4a570997e71b892805a1e71303d09c327af135f in upstream Linux.
Again, it isn't needed in our code as our tree won't run
as a crash dump kernel. But it might be good to align the code
with what is in upstram Linux.

Lastly, your change is already present in upstram Linux,
I'm not sure how I managed to miss adding it to xen-Linux.
Sorry about that :-(

-- 
Horms

commit f4a570997e71b892805a1e71303d09c327af135f
tree 9fe577e7b97ee7365481489f1c263aa1f868e199
parent 25667d675454f2cd258c5fa798a2281af1ef2ae9
author Horms <horms@xxxxxxxxxxxx> 1173177261 -0800
committer Tony Luck <tony.luck@xxxxxxxxx> 1173221274 -0800

[IA64] point saved_max_pfn to the max_pfn of the entire system

Make saved_max_pfn point to max_pfn of entire system.

Without this patch is so that vmcore is zero length on ia64.  This is
because saved_max_pfn was wrongly being set to the max_pfn of the crash
kernel's address space, rather than the max_pfg on the physical memory of
the machine - the whole purpose of vmcore is to access physical memory that
is not part of the crash kernel's addresss space.

Signed-off-by: Simon Horman <horms@xxxxxxxxxxxx>
Signed-off-by: Zou Nan hai <nanhai.zou@xxxxxxxxx>
Sort-Of-Acked-By: Jay Lan <jlan@xxxxxxx>
Signed-off-by: Andrew Morton <akpm@xxxxxxxxxxxxxxxxxxxx>
Signed-off-by: Tony Luck <tony.luck@xxxxxxxxx>

--- 

Rediffed for linux-2.6.18-xen.hg

f4a570997e71b892805a1e71303d09c327af135f
Index: linux-2.6.18-xen.hg/arch/ia64/kernel/efi.c
===================================================================
--- linux-2.6.18-xen.hg.orig/arch/ia64/kernel/efi.c     2008-07-24 
19:24:32.000000000 +1000
+++ linux-2.6.18-xen.hg/arch/ia64/kernel/efi.c  2008-07-24 19:27:40.000000000 
+1000
@@ -21,6 +21,7 @@
  *     Skip non-WB memory and ignore empty memory ranges.
  */
 #include <linux/module.h>
+#include <linux/bootmem.h>
 #include <linux/kernel.h>
 #include <linux/init.h>
 #include <linux/types.h>
@@ -1015,6 +1016,11 @@ efi_memmap_init(unsigned long *s, unsign
                } else
                        ae = efi_md_end(md);
 
+#ifdef CONFIG_CRASH_DUMP
+               /* saved_max_pfn should ignore max_addr= command line arg */
+               if (saved_max_pfn < (ae >> PAGE_SHIFT))
+                       saved_max_pfn = (ae >> PAGE_SHIFT);
+#endif
                /* keep within max_addr= and min_addr= command line arg */
                as = max(as, min_addr);
                ae = min(ae, max_addr);
Index: linux-2.6.18-xen.hg/arch/ia64/mm/contig.c
===================================================================
--- linux-2.6.18-xen.hg.orig/arch/ia64/mm/contig.c      2008-03-19 
14:17:44.000000000 +1100
+++ linux-2.6.18-xen.hg/arch/ia64/mm/contig.c   2008-07-24 19:27:40.000000000 
+1000
@@ -180,12 +180,6 @@ find_memory (void)
 #endif
 
        find_initrd();
-
-#ifdef CONFIG_CRASH_DUMP
-       /* If we are doing a crash dump, we still need to know the real mem
-        * size before original memory map is * reset. */
-       saved_max_pfn = max_pfn;
-#endif
 }
 
 #ifdef CONFIG_SMP
Index: linux-2.6.18-xen.hg/arch/ia64/mm/discontig.c
===================================================================
--- linux-2.6.18-xen.hg.orig/arch/ia64/mm/discontig.c   2008-07-24 
19:25:14.000000000 +1000
+++ linux-2.6.18-xen.hg/arch/ia64/mm/discontig.c        2008-07-24 
19:27:40.000000000 +1000
@@ -512,11 +512,6 @@ void __init find_memory(void)
        max_pfn = max_low_pfn;
 
        find_initrd();
-#ifdef CONFIG_CRASH_DUMP
-       /* If we are doing a crash dump, we still need to know the real mem
-        * size before original memory map is * reset. */
-       saved_max_pfn = max_pfn;
-#endif
 }
 
 #ifdef CONFIG_SMP

_______________________________________________
Xen-ia64-devel mailing list
Xen-ia64-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-ia64-devel