[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: [Xen-ia64-devel] virtual mem map?


  • To: "Greg Edwards" <edwardsg@xxxxxxx>, <xen-ia64-devel@xxxxxxxxxxxxxxxxxxx>
  • From: "Magenheimer, Dan (HP Labs Fort Collins)" <dan.magenheimer@xxxxxx>
  • Date: Wed, 15 Jun 2005 14:58:13 -0700
  • Delivery-date: Wed, 15 Jun 2005 21:57:12 +0000
  • List-id: DIscussion of the ia64 port of Xen <xen-ia64-devel.lists.xensource.com>
  • Thread-index: AcVx7c8lGpOl3fazSuionhZeC8egWgAAwRfg
  • Thread-topic: [Xen-ia64-devel] virtual mem map?

There was the beginning of a discussion regarding Xen on NUMA
machines recently on the following thread:

http://article.gmane.org/gmane.comp.emulators.xen.devel/10859

I think it would be great to have some better "large" (e.g.
NUMA, discontig, etc) memory support on Xen.  However, this
is almost entirely in core Xen code now so it would have
to be coordinated with the core team and at least not break x86.

You may recall that I was trying to preserve the capability
to support NUMA and discontig machines, but was overruled.
See:

http://article.gmane.org/gmane.comp.emulators.xen.devel/7795

In any case, for what it's worth, you certainly have "my
blessing".  Feel free to start a new thread on xen-devel
suggesting cooperation.

Dan


> -----Original Message-----
> From: xen-ia64-devel-bounces@xxxxxxxxxxxxxxxxxxx 
> [mailto:xen-ia64-devel-bounces@xxxxxxxxxxxxxxxxxxx] On Behalf 
> Of Greg Edwards
> Sent: Wednesday, June 15, 2005 3:04 PM
> To: xen-ia64-devel@xxxxxxxxxxxxxxxxxxx
> Subject: [Xen-ia64-devel] virtual mem map?
> 
> Dan,
> 
> Currently, arch/ia64/efi.c has the following hunk added to it:
> 
>     330 // this is a temporary hack to avoid CONFIG_VIRTUAL_MEM_MAP
>     331                 if (md->phys_addr >= 0x100000000) continue;
> 
> This is problematic right off the bat for SGI systems, since we have
> huge holes in the efi memory map.  For instance, on a small 
> 2p/2GB box,
> it looks like:
> 
> mem00: type=13, attr=0x8000000000000009, 
> range=[0x0000000001000000-0x0000000002000000) (16MB)
> mem01: type=8, attr=0x9, 
> range=[0x0000003000000000-0x0000003000010000) (0MB)
> mem02: type=6, attr=0x8000000000001001, 
> range=[0x0000003000010000-0x0000003000080000) (0MB)
> mem03: type=4, attr=0x1, 
> range=[0x0000003000080000-0x0000003000400000) (3MB)
> mem04: type=6, attr=0x8000000000001009, 
> range=[0x0000003000400000-0x0000003002000000) (28MB)
> mem05: type=6, attr=0x8000000000000009, 
> range=[0x0000003002000000-0x0000003003000000) (16MB)
> mem06: type=4, attr=0x9, 
> range=[0x0000003003000000-0x0000003006000000) (48MB)
> mem07: type=7, attr=0x9, 
> range=[0x0000003006000000-0x0000003014000000) (224MB)
> mem08: type=2, attr=0x9, 
> range=[0x0000003014000000-0x0000003014cb5000) (12MB)
> mem09: type=7, attr=0x9, 
> range=[0x0000003014cb5000-0x0000003079326000) (1606MB)
> mem10: type=2, attr=0x9, 
> range=[0x0000003079326000-0x000000307a326000) (16MB)
> mem11: type=7, attr=0x9, 
> range=[0x000000307a326000-0x000000307a3de000) (0MB)
> mem12: type=2, attr=0x9, 
> range=[0x000000307a3de000-0x000000307a3f8000) (0MB)
> mem13: type=1, attr=0x9, 
> range=[0x000000307a3f8000-0x000000307a452000) (0MB)
> mem14: type=4, attr=0x9, 
> range=[0x000000307a452000-0x000000307a7fe000) (3MB)
> mem15: type=6, attr=0x8000000000000009, 
> range=[0x000000307a7fe000-0x000000307b800000) (16MB)
> mem16: type=4, attr=0x9, 
> range=[0x000000307b800000-0x000000307b801000) (0MB)
> mem17: type=7, attr=0x9, 
> range=[0x000000307b801000-0x000000307b86e000) (0MB)
> mem18: type=4, attr=0x9, 
> range=[0x000000307b86e000-0x000000307b894000) (0MB)
> mem19: type=7, attr=0x9, 
> range=[0x000000307b894000-0x000000307b895000) (0MB)
> mem20: type=4, attr=0x9, 
> range=[0x000000307b895000-0x000000307b9fe000) (1MB)
> mem21: type=7, attr=0x9, 
> range=[0x000000307b9fe000-0x000000307bd72000) (3MB)
> mem22: type=5, attr=0x8000000000000009, 
> range=[0x000000307bd72000-0x000000307bdac000) (0MB)
> mem23: type=3, attr=0x9, 
> range=[0x000000307bdac000-0x000000307bdfe000) (0MB)
> mem24: type=7, attr=0x9, 
> range=[0x000000307bdfe000-0x000000307be10000) (0MB)
> mem25: type=5, attr=0x8000000000000009, 
> range=[0x000000307be10000-0x000000307be7e000) (0MB)
> mem26: type=7, attr=0x9, 
> range=[0x000000307be7e000-0x000000307bea2000) (0MB)
> mem27: type=6, attr=0x8000000000000009, 
> range=[0x000000307bea2000-0x000000307c000000) (1MB)
> mem28: type=12, attr=0x8000000000000001, 
> range=[0x1ffffffffc000000-0x2000000000000000) (64MB)
> 
> Xen doesn't find a place to stash the dom0 kernel.
> 
> Do I have your blessing to look at adding CONFIG_VIRTUAL_MEM_MAP and
> CONFIG_DISCONTIGMEM support, or are there other suggestions out there
> about how to handle it?
> 
> Greg
> 
> _______________________________________________
> Xen-ia64-devel mailing list
> Xen-ia64-devel@xxxxxxxxxxxxxxxxxxx
> http://lists.xensource.com/xen-ia64-devel
> 

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


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.