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/
Home Products Support Community News


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

To: "Greg Edwards" <edwardsg@xxxxxxx>, <xen-ia64-devel@xxxxxxxxxxxxxxxxxxx>
Subject: RE: [Xen-ia64-devel] virtual mem map?
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
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
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/cgi-bin/mailman/listinfo/xen-ia64-devel>, <mailto:xen-ia64-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-ia64-devel>, <mailto:xen-ia64-devel-request@lists.xensource.com?subject=unsubscribe>
Sender: xen-ia64-devel-bounces@xxxxxxxxxxxxxxxxxxx
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:


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.


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.


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

<Prev in Thread] Current Thread [Next in Thread>