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

[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


 


Rackspace

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