Re: [Xen-devel] questions about ballooning

[weiming <zephyr.zhao@xxxxxxxxx>]

Hi Daniel,

Very appreciate for your so detailed explanation. You clarified some of my confusion. Before I post my question here, I read the paper "Memory resource Management in VMware ESX server", "art of virtualization", read Xen manual, checked the xen Wiki and searched in the maillist archive but can't get a complete  picture about balloon.

1) when a guesting os starts, how does it determine the amount of physical memory? i.e. which value determines the number of entries in mem_map? Is the value specified in configuration file?  

2) what's the exact role that xm mem-max plays?  I can set it to be higher than the value in configuration file.  I think that it just sets the "new_target" to balloon via xenbus or /proc/xen/balloon, right? 

3) Once some pages are "ballooned out", these pages will be utilized by other domains, so if we later try to restore to initial status, how does VMM find available pages? 

In increase_reservation(),
...
rc = HYPERVISOR_ memory_op(XENMEM_populate_physmap, &reservation)
if (rc < nr_pages)
 ...

In my understanding, hypervisor *tries* to find some free pages to return to the os. 

4)  in 
balloon.c, there are some functions that I can't find the calling sites. they are dealloc_pte_fn, alloc_empty_pages_and_pagevec, balloon_update_driver_allowance, etc. Are they be called back by hypervisor?

Thanks a lot in advance!
Weiming

On 11/4/07, Daniel Stodden <stodden@xxxxxxxxxx> wrote:

On Sat, 2007-11-03 at 21:31 -0400, weiming wrote:
> I'm interested in the ballooning, so I read the balloon.c
> I have a questions:
>
> How is the ballooned pages be used? After decrease_reservation(),
> balloon driver tells the vmm the pages that it gets. Then, how xen
> utilizes this reclaimed pages?

the pages are unmapped by the domain, i.e. there are no further
references to them. the VMM can verify this. after the vmm gets the page
list, no new references will be allowed, so the hypervisor knows for
sure that the domain won't mess around with these pages afterwards. it's
'gone', and only the balloon knows that it's not only allocated, but
indeed *gone*.

alloc/free is maybe best understood like this: to a native guest kernel,
there is no such concept of memory 'disappearing'. machine memory does
not just disappear (except for such deeply esoteric things like memory
hotplug). however, that's what is happening under the VMM. but still,
there's the possibly of taking memory away from the kernel: by
allocating it. as long as the ballon driver allocated that page, no
other entity in the system may access it.

(note that security were at risk with a buggy guest kernel. that's why
this unmapping thing is so important. the VMM must insist that the guest
_cannot_ access the page anymore).

> When other domains (both dom0 and domU) requests increasing
> reservation, will xen allocate these pages to them?

yes. reusing those pages in other domains is the sole purpose of taking
them. there's no point in letting memory idle around. an ideal system
has 100% memory utilization. those frames not used by processes are left
to buffers and caches. fundamental good-OS principle.

> If yes, from increasing_reservation(), it seems that balloon just
> releases the pages that it previously occupied.
> If no, where do these "ballooned" pages go?

it not only releases them, it reinstalls them in the kernel address
space, and reassigns them to the kernel physical/machine translation.
note that it does not need to be the same machine frame. it may be any
other page retrieved from the VMM. that's what the phys_to_machine,
machphys_update and update_va_mapping calls are good for.

regards,
daniel

--
Daniel Stodden
LRR     -      Lehrstuhl für Rechnertechnik und Rechnerorganisation
Institut für Informatik der TU München             D-85748 Garching
http://www.lrr.in.tum.de/~stodden         mailto:stodden@xxxxxxxxxx
PGP Fingerprint: F5A4 1575 4C56 E26A 0B33  3D80 457E 82AE B0D8 735B



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

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