[PATCH] make ballooning up to maxmem work

[PATCH] make ballooning up to maxmem work

[Rik van Riel]

[-- Attachment #1: Type: text/plain, Size: 590 bytes --]

Because XENMEM_maximum_reservation is rumored to change meaning in
the future, this patch adds a third amount-of-memory operation to
HYPERVISOR_memory_op() - XENMEM_maximum_memory.

This should make it possible to simply specify the maximum amount
of memory a guest will have in /etc/xen/<guest> instead of having
to pass it on the kernel commandline.

A next step would be to split out the maxmem values into two
different ones in the guest config file and the tools, but I'm
not quite sure what name to use there...

Signed-off-by: Rik van Riel <riel@redhat.com>

-- 
All Rights Reversed

[-- Attachment #2: balloon-third-way --]
[-- Type: text/plain, Size: 3414 bytes --]

Because XENMEM_maximum_reservation is rumored to change meaning in
the future, this patch adds a third amount-of-memory operation to
HYPERVISOR_memory_op() - XENMEM_maximum_memory.

This should make it possible to simply specify the maximum amount
of memory a guest will have in /etc/xen/<guest> instead of having
to pass it on the kernel commandline.

A next step would be to split out the maxmem values into two
different ones in the guest config file and the tools, but I'm
not quite sure what name to use there...


Signed-off-by: Rik van Riel <riel@redhat.com>

diff -r ea457d9d3fb2 linux-2.6-xen-sparse/arch/x86_64/kernel/e820-xen.c
--- a/linux-2.6-xen-sparse/arch/x86_64/kernel/e820-xen.c	Mon Nov 20 16:59:07 2006 +0000
+++ b/linux-2.6-xen-sparse/arch/x86_64/kernel/e820-xen.c	Tue Nov 21 15:58:56 2006 -0500
@@ -583,6 +583,7 @@ void __init setup_memory_region(void)
 	 * the boot process we know we have plenty slack space.
 	 */
 	struct e820entry map[E820MAX];
+	unsigned long arg = DOMID_SELF;
 
 	memmap.nr_entries = E820MAX;
 	set_xen_guest_handle(memmap.buffer, map);
@@ -591,7 +592,11 @@ void __init setup_memory_region(void)
 	if ( rc == -ENOSYS ) {
 		memmap.nr_entries = 1;
 		map[0].addr = 0ULL;
-		map[0].size = xen_start_info->nr_pages << PAGE_SHIFT;
+		rc = HYPERVISOR_memory_op(XENMEM_maximum_memory, &arg);
+		if ( rc < 0 )
+			map[0].size = xen_start_info->nr_pages << PAGE_SHIFT;
+		else
+			map[0].size = rc << PAGE_SHIFT;
 		/* 8MB slack (to balance backend allocations). */
 		map[0].size += 8 << 20;
 		map[0].type = E820_RAM;
diff -r ea457d9d3fb2 linux-2.6-xen-sparse/include/asm-i386/mach-xen/setup_arch_post.h
--- a/linux-2.6-xen-sparse/include/asm-i386/mach-xen/setup_arch_post.h	Mon Nov 20 16:59:07 2006 +0000
+++ b/linux-2.6-xen-sparse/include/asm-i386/mach-xen/setup_arch_post.h	Tue Nov 21 15:58:56 2006 -0500
@@ -18,6 +18,7 @@ static char * __init machine_specific_me
 	 * the boot process we know we have plenty slack space.
 	 */
 	struct e820entry map[E820MAX];
+	unsigned long arg = DOMID_SELF;
 
 	memmap.nr_entries = E820MAX;
 	set_xen_guest_handle(memmap.buffer, map);
@@ -26,7 +27,11 @@ static char * __init machine_specific_me
 	if ( rc == -ENOSYS ) {
 		memmap.nr_entries = 1;
 		map[0].addr = 0ULL;
-		map[0].size = PFN_PHYS(xen_start_info->nr_pages);
+		rc = HYPERVISOR_memory_op(XENMEM_maximum_memory, &arg);
+		if ( rc < 0 )
+			map[0].size = PFN_PHYS(xen_start_info->nr_pages);
+		else
+			map[0].size = PFN_PHYS(rc);
 		/* 8MB slack (to balance backend allocations). */
 		map[0].size += 8ULL << 20;
 		map[0].type = E820_RAM;
diff -r ea457d9d3fb2 xen/arch/x86/mm.c
--- a/xen/arch/x86/mm.c	Mon Nov 20 16:59:07 2006 +0000
+++ b/xen/arch/x86/mm.c	Tue Nov 21 15:58:56 2006 -0500
@@ -2974,6 +2974,8 @@ long arch_memory_op(int op, XEN_GUEST_HA
         break;
     }
 
+    /* When implementing this, make sure to create a map up to the
+     * maximum amount of memory the guest will ever need. */
     case XENMEM_memory_map:
     {
         return -ENOSYS;
diff -r ea457d9d3fb2 xen/common/memory.c
--- a/xen/common/memory.c	Mon Nov 20 16:59:07 2006 +0000
+++ b/xen/common/memory.c	Tue Nov 21 15:58:56 2006 -0500
@@ -588,6 +588,7 @@ long do_memory_op(unsigned long cmd, XEN
 
     case XENMEM_current_reservation:
     case XENMEM_maximum_reservation:
+    case XENMEM_maximum_memory:
         if ( copy_from_guest(&domid, arg, 1) )
             return -EFAULT;
 

[-- Attachment #3: Type: text/plain, Size: 138 bytes --]

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

Re: [PATCH] make ballooning up to maxmem work

[Glauber de Oliveira Costa]

  
>      case XENMEM_current_reservation:
>      case XENMEM_maximum_reservation:
> +    case XENMEM_maximum_memory:
>          if ( copy_from_guest(&domid, arg, 1) )
>              return -EFAULT;

This still makes use of d->max_pages in return. Isn't it supposed to
change in the future too? IIRC, according to Keir, max_pages will track 
the _current_ number of pages, differing from tot_pages only in a brief
timeframe in which you balloon, but tot_pages was not yet updated.


-- 
Glauber de Oliveira Costa
Red Hat Inc.
"Free as in Freedom"

Re: Re: [PATCH] make ballooning up to maxmem work

[Keir Fraser]

On 22/11/06 10:40, "Glauber de Oliveira Costa" <gcosta@redhat.com> wrote:

>>      case XENMEM_current_reservation:
>>      case XENMEM_maximum_reservation:
>> +    case XENMEM_maximum_memory:
>>          if ( copy_from_guest(&domid, arg, 1) )
>>              return -EFAULT;
> 
> This still makes use of d->max_pages in return. Isn't it supposed to
> change in the future too? IIRC, according to Keir, max_pages will track
> the _current_ number of pages, differing from tot_pages only in a brief
> timeframe in which you balloon, but tot_pages was not yet updated.

This adds a level of indirection at least, but really we may as well
implement the XENMEM_memory_map hypercall. Then there is no guest
modification required.

 -- Keir

Re: Re: [PATCH] make ballooning up to maxmem work

[Glauber de Oliveira Costa]

On Wed, Nov 22, 2006 at 11:18:39AM +0000, Keir Fraser wrote:
> 
> 
> 
> On 22/11/06 10:40, "Glauber de Oliveira Costa" <gcosta@redhat.com> wrote:
> 
> >>      case XENMEM_current_reservation:
> >>      case XENMEM_maximum_reservation:
> >> +    case XENMEM_maximum_memory:
> >>          if ( copy_from_guest(&domid, arg, 1) )
> >>              return -EFAULT;
> > 
> > This still makes use of d->max_pages in return. Isn't it supposed to
> > change in the future too? IIRC, according to Keir, max_pages will track
> > the _current_ number of pages, differing from tot_pages only in a brief
> > timeframe in which you balloon, but tot_pages was not yet updated.
> 
> This adds a level of indirection at least, but really we may as well
> implement the XENMEM_memory_map hypercall. Then there is no guest
> modification required.

We may need guest modifications anyway, since currently no actions are
performed if the memory_map call does not return ENOSYS. 
 

-- 
Glauber de Oliveira Costa
Red Hat Inc.
"Free as in Freedom"