From mboxrd@z Thu Jan 1 00:00:00 1970 From: Sarina Canelake Subject: [RFC] new totalmem= boot parameter Date: Mon, 19 Jul 2010 10:56:52 -0700 (PDT) Message-ID: <682e4bcf-71e3-4b49-a25b-79404ae470bb@default> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="__127956221288922046abhmt021" Return-path: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: xen-devel@lists.xensource.com List-Id: xen-devel@lists.xenproject.org --__127956221288922046abhmt021 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline We have a need for ensuring the total RAM available to [Xen / the kernel] a= t boot is X MB because there are situations in which you wish to limit the = amount of RAM available to a box. The existing mem=3D option doesn't work b= ecause it limits the maximum physical address, NOT the amount of available = RAM. Many, if not all, systems contain a substantial memory hole below 4 Gb= , typically a 0.5 or 1 Gb hole from 3-4 Gb. Thus, on a system with 6 Gb of = RAM, requesting mem=3D4096M will yield a box with maximum physical address = in the 4 Gb neighborhood but perhaps only 3 or 3.5 actual gigs of RAM avail= able. So I propose to add a new kernel argument, which I call totalmem, that limi= ts the total amount of memory available, ignoring holes. So requesting tota= lmem=3D4096M in the preceding example, the maximum physical address may ext= end much higher depending on the size of the memory map hole. An example pa= tch is attached; it doesn't apply directly to xen-unstable but should provi= de an example implementation for discussion; I implemented it to conform to= the changes made to the clip_to_limit function in xen-unstable.=20 Alternately, we could modify mem=3D to do this; according to documentation,= it seems that the behavior of totalmem reflects the designer's goal for me= m. However, I would be worried about issues of backwards compatibility, as = people may already be exploiting the current functionality of mem=3D to dir= ectly cut off the address space. Comments? (P.S. This is my first post to= xen-devel so please be kind :) Thanks, Sarina --__127956221288922046abhmt021 Content-Type: text/x-patch; charset=UTF-8; name="xen-add-totalmem-kernel-arg.patch" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="xen-add-totalmem-kernel-arg.patch" Adds a new kernel arg, totalmem=3D, to specify the amount of physical memor= y=20 (whereas the prveious available option had only been mem=3D, which limits t= he address of physical memory) 07/19/2010 patch written by Sarina Canelake (sarina.canelake@oracle.com) diff -up xen/arch/x86/e820.c.orig xen/arch/x86/e820.c --- xen/arch/x86/e820.c.orig=092010-07-19 11:50:49.000000000 -0600 +++ xen/arch/x86/e820.c=092010-07-19 11:52:13.000000000 -0600 @@ -10,10 +10,14 @@ #include #include =20 -/* opt_mem: Limit of physical RAM. Any RAM beyond this point is ignored. *= / +/* opt_mem: Limit address of physical RAM. Any RAM beyond this point is ig= nored. */ static unsigned long long __initdata opt_mem; size_param("mem", opt_mem); =20 +/* opt_totalmem: Limit amount of physical RAM; any RAM beyond this point i= s ignored. */ +static unsigned long long __initdata opt_totalmem; +size_param("totalmem", opt_totalmem); + /* opt_nomtrr_check: Don't clip ram to highest cacheable MTRR. */ static int __initdata e820_mtrr_clip =3D -1; boolean_param("e820-mtrr-clip", e820_mtrr_clip); @@ -416,6 +420,77 @@ static void __init clip_to_limit(uint64_ } } =20 +static void __init clip_to_totalmem_limit(uint64_t totalmem_limit, char *w= arnmsg) +{ + int i; + char _warnmsg[160]; + uint64_t old_limit, test_limit, start_addr =3D 0; =20 +=20 + for ( ; ; ) + { + test_limit =3D 0; old_limit =3D 0; =20 + /* Find a RAM region needing clipping. */ + for ( i=3D0; i < e820.nr_map; i++ ) +=09{ +=09 /* Try adding this region's memory; test if exceeds */ +=09 test_limit =3D old_limit + e820.map[i].size; =20 +=09 if ( (e820.map[i].type =3D=3D E820_RAM) && +=09 (test_limit > totalmem_limit) ) =20 +=09 { +=09 /* If exceeds we need to mark this region as unusable. Determine +=09=09 the starting address of where to start the unusable segment. */ +=09 if ( start_addr =3D=3D 0 ) { =20 +=09=09start_addr =3D e820.map[i].addr + (totalmem_limit - old_limit); + +=09 } +=09 else=20 +=09=09start_addr =3D e820.map[i].addr; + =20 +=09 break; +=09 } + =20 +=09 old_limit =3D test_limit; =20 +=09} + =20 + /* If none found, we are done. */ + if ( i =3D=3D e820.nr_map ) +=09break; + =20 + /* We try to convert clipped RAM areas to E820_UNUSABLE=20 +=09 (need to give an address to start from marking at unusable)*/ + if ( e820_change_range_type(&e820, start_addr, +=09=09=09=09 e820.map[i].addr + e820.map[i].size, +=09=09=09=09 E820_RAM, E820_UNUSABLE) ) +=09continue; + + /* + * If the type change fails (e.g., not space in table) then we clip = or=20 + * delete the region as appropriate. + */ + if ( old_limit < totalmem_limit ) + { + e820.map[i].size =3D totalmem_limit - old_limit; =20 + } + else + { +=09 memmove(&e820.map[i], &e820.map[i+1], +=09=09 (e820.nr_map - i - 1) * sizeof(struct e820entry)); +=09 e820.nr_map--; + } + } =20 + =20 + if ( old_limit ) + { + if ( warnmsg ) +=09{ +=09 snprintf(_warnmsg, sizeof(_warnmsg), warnmsg, (long)(totalmem_limit>>= 30)); +=09 printk("WARNING: %s\n", _warnmsg); +=09} + printk("Truncating RAM from %lukB to %lukB\n", +=09 (unsigned long)(old_limit >> 10), (unsigned long)(totalmem_limit >= > 10)); + } =20 +} + /* Conservative estimate of top-of-RAM by looking for MTRR WB regions. */ #define MSR_MTRRphysBase(reg) (0x200 + 2 * (reg)) #define MSR_MTRRphysMask(reg) (0x200 + 2 * (reg) + 1) @@ -513,6 +588,9 @@ static void __init machine_specific_memo if ( opt_mem ) clip_to_limit(opt_mem, NULL); =20 + else if ( opt_totalmem ) + clip_to_totalmem_limit(opt_totalmem, NULL); + #ifdef __i386__ clip_to_limit((1ULL << 30) * MACHPHYS_MBYTES, "Only the first %lu GB of the physical memory map " --__127956221288922046abhmt021 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel --__127956221288922046abhmt021--