Re: [Xen-devel] question about running vm change its mem maxsize

[Daniel Stodden <stodden@xxxxxxxxxx>]

On Mon, 2007-03-19 at 09:20 +0800, tgh wrote:
> hi
>  I  read the code of xc_linux_build() and xc_domain_setmaxmem(),and I am 
> confused about how does "xm mem-max" change the  max  size  of mem  for  
> a  running  VM
> 
>  In xc_domain_setmaxmem() ,the XEN_DOMCTL_max_mem has been called ,and  
> just  does  "d->max_pages = new_max;"

that variable determines the maximum size. the code verifies that the
new size won't be below the previous one, and therefore just needs to
readjust it.

it doesn't actually have to allocate memory. this is done on demand,
i.e. as soon as the domain references a new page frame within it's
virtual machine address space.

> while in the xc_linux_build(),  before the vm boots up,the maxsize pfn 
> is alloced in an array with fixsize, page_array = malloc(nr_pages * 
> sizeof(unsigned long))

i suppose you misunderstood what that call really does. it's not
changing the maximum vm size, but allocating the initial number of pages
required to load the guest operating system image into. that's typically
much less than d->max_pages.

> then how does  a running vm  changes its mem maxsize ,especially for 
> expanding its mem maxsize?

for an unprivileged guest os, there is no such call. similar in the way
your desktop machine (hopefully) won't call dell ordering more RAM
without your knowledge.

changing machine size is an administrative operation. it is defined
during VM creating, and potential subject to refinement by the
administrator on dom0.

what the guest system does in order to get 'more memory' is, from the
guest system point of view, more or less equivalent to what the guest
operating system on a physical host would do: manage physical memory,
find a free page frame, map it in one or more page tables, then start
using it. xen detects that process of mapping this page frame, and
performs the allocation. but, how this is done in detail largely depends
on the type of VM (hardware-based, paravirtual, etc), and even then
there are different variants.

hth.

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