Just one suggestion, for xen-hvm-auto-balloon.diff, how about
xc.domain_setmaxmem(self.domid, self.info['memory'] * 1024)
The maxmem would be used to check when guest try to increase memory.
Also, does anyone know the what the BALLOON_OUT_SLACK on
tools/python/xen/xend/balloon.py stands for? The comments said it is
"physinfo details are rounded".
>[mailto:xen-devel-bounces@xxxxxxxxxxxxxxxxxxx] On Behalf Of
>Sent: Friday, May 19, 2006 1:04 AM
>Subject: [Xen-devel] [PATCH] Fix auto-ballooning of dom0 for
>I've been trying to make the auto-ballooning of domain 0 work reliably
>for HVM domains.
>Patch #1 is a simple bug fix, in preparation for patch #2. Patch #2
>tries to calculate how much memory is needed for HVM domains (XenSource
>bug #521) and is certainly open for discussion. Patches apply cleanly
>to both 3.0-testing and unstable.
>Patch #1 (xen-hvm-auto-balloon.diff):
>When a domain (whether para- or fully-virtualized) reports how much
>overhead memory it requires (via getDomainMemory in image.py), all such
>memory was immediately allocated to the domain itself. This is
>certainly incorrect for HVM domains, since additional
>increase_reservation calls are made later in qemu. Since all ballooned
>memory is already taken, qemu will fail. The fix is to treat the
>requested memory size and the overhead size as separate values. The
>requested memory size is immediately allocated to the new domain; the
>overhead is left unallocated for whatever else might need it later.
>Patch #2 (xen-get-dom-memory.diff):
>This patch calculates the overhead needed for HVM domains. If HVM is
>supported by the hardware, I add a little ballooning overhead to
>paravirtualized VMs also, to avoid low-memory situations. (There are
>various unchecked alloc_domheap_pages calls in shadow*.c that I am
>trying to avoid tripping over for now...) The values in this
>fine on 32 bit; I may update them later based on feedback
>on 64 bit.
Xen-devel mailing list