Xen devel - May 2006 - Re: [Xen-changelog] Convert x86/64 Linux to use the new memory map hypercall.

* Xen patchbot-unstable (patchbot-unstable@lists.xensource.com)
wrote:
> # HG changeset patch
> # User Ian.Campbell@xensource.com
> # Node ID 8fa46042348c33429245312e58ab71c437bf9920
> # Parent  d61211a6c273de817af91944c666ffb6406c6798
> Convert x86/64 Linux to use the new memory map hypercall.
> --- a/linux-2.6-xen-sparse/include/asm-x86_64/e820.h	Mon May 22 09:23:03
2006 +0100
> +++ b/linux-2.6-xen-sparse/include/asm-x86_64/e820.h	Mon May 22 09:23:15
2006 +0100
> @@ -45,12 +45,12 @@ extern void setup_memory_region(void);
>  extern void setup_memory_region(void);
>  extern void contig_e820_setup(void); 
>  extern unsigned long e820_end_of_ram(void);
> -extern void e820_reserve_resources(void);
> +extern void e820_reserve_resources(struct e820entry *e820, int nr_map);
>  extern void e820_print_map(char *who);
>  extern int e820_mapped(unsigned long start, unsigned long end, unsigned
type);
>  
>  extern void e820_bootmem_free(pg_data_t *pgdat, unsigned long
start,unsigned long end);
> -extern void e820_setup_gap(void);
> +extern void e820_setup_gap(struct e820entry *e820, int nr_map);
>  extern unsigned long e820_hole_size(unsigned long start_pfn,
>  				    unsigned long end_pfn);
This breaks the native build.  I fixed it with the ugly hack below in the
tip.xen[1] tree when merging the changes with 2.6.17-rc5, but will need a
cleaner solution.  Also, the upstream changes make the i386 e820 changes
less useful from the point of view of minimizing diffs from upstream.
For dom0 why not use the machine map to start with?  I don''t see the
extra value of the two stage map.

[1] http://xenbits.xensource.com/ext/linux-2.6.tip-xen.hg

--- 2.6.17-rc5-merge/include/asm-x86_64/e820.h.orig	Thu May 25 08:50:17 2006
+0700
+++ 2.6.17-rc5-merge/include/asm-x86_64/e820.h	Fri May 26 04:49:26 2006 -0400
@@ -45,13 +45,18 @@ extern void setup_memory_region(void);
 extern void setup_memory_region(void);
 extern void contig_e820_setup(void); 
 extern unsigned long e820_end_of_ram(void);
+#ifndef CONFIG_XEN
 extern void e820_reserve_resources(void);
+extern void e820_setup_gap(void);
+#else
+extern void e820_reserve_resources(struct e820entry *e820, int nr_map);
+extern void e820_setup_gap(struct e820entry *e820, int nr_map);
+#endif
 extern void e820_print_map(char *who);
 extern int e820_any_mapped(unsigned long start, unsigned long end, unsigned
type);
 extern int e820_all_mapped(unsigned long start, unsigned long end, unsigned
type);
 
 extern void e820_bootmem_free(pg_data_t *pgdat, unsigned long start,unsigned
long end);
-extern void e820_setup_gap(void);
 extern unsigned long e820_hole_size(unsigned long start_pfn,
 				    unsigned long end_pfn);
 

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

On Fri, 2006-05-26 at 02:17 -0700, Chris Wright wrote:
> This breaks the native build.  I fixed it with the ugly hack below in the
> tip.xen[1] tree when merging the changes with 2.6.17-rc5, but will need a
> cleaner solution.
Ooops. Sorry.

I''ll move linux-2.6-xen-sparse/include/asm-x86_64/e820.h to
linux-2.6-xen-sparse/include/asm-x86_64/mach-xen/asm/e820.h then the
native build will pickup the unmodified e820.h.
>   Also, the upstream changes make the i386 e820 changes
> less useful from the point of view of minimizing diffs from upstream.
> For dom0 why not use the machine map to start with?  I don''t see
the
> extra value of the two stage map.
The machine map contains the actual physical memory layout, which has no
relationship with the para-virtual layout, even in dom0.

Ian.



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

* Ian Campbell (Ian.Campbell@xensource.com) wrote:
> I''ll move linux-2.6-xen-sparse/include/asm-x86_64/e820.h to
> linux-2.6-xen-sparse/include/asm-x86_64/mach-xen/asm/e820.h then the
> native build will pickup the unmodified e820.h.
I looked at that last night, but didn''t see the
include/asm-x86_46/mach-xen/asm/ dir being used.
/me looks again
Ok, not sure how I missed it, was clearly past my bedtime ;-)
> >   Also, the upstream changes make the i386 e820 changes
> > less useful from the point of view of minimizing diffs from upstream.
> > For dom0 why not use the machine map to start with?  I don''t
see the
> > extra value of the two stage map.
> 
> The machine map contains the actual physical memory layout, which has no
> relationship with the para-virtual layout, even in dom0.
I was picturing a single sane map from the start.  So proper memory and
other resources.

thanks,
-chris

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