Re: [Xen-devel] questions about ballooning

[Daniel Stodden <stodden@xxxxxxxxxx>]

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