From: Rik van Riel <riel@redhat.com>
To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
gcosta@redhat.com
Subject: [PATCH] make ballooning up to maxmem work
Date: Tue, 21 Nov 2006 16:00:21 -0500 [thread overview]
Message-ID: <456368E5.70906@redhat.com> (raw)
[-- 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
next reply other threads:[~2006-11-21 21:00 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-11-21 21:00 Rik van Riel [this message]
2006-11-22 10:40 ` [PATCH] make ballooning up to maxmem work Glauber de Oliveira Costa
2006-11-22 11:18 ` Keir Fraser
2006-11-22 12:47 ` Glauber de Oliveira Costa
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=456368E5.70906@redhat.com \
--to=riel@redhat.com \
--cc=gcosta@redhat.com \
--cc=xen-devel@lists.xensource.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.