Attached patch implements save/restore/migration/livemigration
for transcendent memory ("tmem"). Without this patch, domains
using tmem may in some cases lose data when doing save/restore
or migrate/livemigrate. Also included in this patch is
support for a new (privileged) hypercall for authorizing
domains to share pools; this provides the foundation to
accomodate upstream linux requests for security for shared
pools.
Signed-off-by: Dan Magenheimer <dan.magenheimer@oracle.com>
Tmem, when called from a tmem-capable (paravirtualized) guest, makes
use of otherwise unutilized ("fallow") memory to create and manage
pools of pages that can be accessed from the guest either as
"ephemeral" pages or as "persistent" pages. In either case, the pages
are not directly addressible by the guest, only copied to and fro via
the tmem interface. Ephemeral pages are a nice place for a guest to
put recently evicted clean pages that it might need again; these pages
can be reclaimed synchronously by Xen for other guests or other uses.
Persistent pages are a nice place for a guest to put "swap" pages to
avoid sending them to disk. These pages retain data as long as the
guest lives, but count against the guest memory allocation.
Tmem pages may optionally be compressed and, in certain cases, can be
shared between guests. Tmem also handles concurrency nicely and
provides limited QoS settings to combat malicious DoS attempts.
Save/restore and live migration support is not yet provided.
Tmem is primarily targeted for an x86 64-bit hypervisor. On a 32-bit
x86 hypervisor, it has limited functionality and testing due to
limitations of the xen heap. Nearly all of tmem is
architecture-independent; three routines remain to be ported to ia64
and it should work on that architecture too. It is also structured to
be portable to non-Xen environments.
Tmem defaults off (for now) and must be enabled with a "tmem" xen boot
option (and does nothing unless a tmem-capable guest is running). The
"tmem_compress" boot option enables compression which takes about 10x
more CPU but approximately doubles the number of pages that can be
stored.
Tmem can be controlled via several "xm" commands and many interesting
tmem statistics can be obtained. A README and internal specification
will follow, but lots of useful prose about tmem, as well as Linux
patches, can be found at http://oss.oracle.com/projects/tmem .
Signed-off-by: Dan Magenheimer <dan.magenheimer@oracle.com>
c/s 18960 introduced a bug when xend balloons memory. The function
balloon.free requires a reference to a XendDomainInfo object, which is
missing in one call of this function. Attached patch fixes this. Also
replaced the variable name "self" in the (classless) function with
something more descriptive.
Signed-off-by: Andre Przywara <andre.przywara@amd.com>
Reported-by: Maik Hentsche <maik.hentsche@amd.com>
Recently we find a bug on Nahelem machine (totally with two nodes, 6G
memory (3G in each node):
- Start a HVM guest with its all VCPUS pinned to node1, so all its
memory is allocated from node1.
- Reboot the HVM.
- There will be some memory allocated from node0 even there is enough
free memory on node1.
Reason: For security issues, xen will not put all the pages of a dying
hvm to domheap directly, but put them in scrub list and wait for handled
by page_scrub_softirq(). If the dying hvm have a lot of memory,
page_scrub_softirq() will not handle all of them before the start the
hvm. There are some pages belong to node1 still in scrub list, new hvm
can't use pages in it. So this hvm will get different memory
distribution than before. Before changeset 18304, page_scrub_softirq()
can be excuted parallel between all the cpus. Changeset 18305
serialise page_scrub_softirq() and Changeset 18307 serialise
page_scrub_softirq() with a new lock to avoid holding up acquiring
page_scrub_lock in free_domheap_pages(). Those changeset slow the ability
to handle pages in scrub list. So the bug becomes more obvious after.
Patch: This patch modifiers balloon.free to avoid this bug. After
patch, balloon.free will check whether current machine is a numa
system and the new created hvm has all its vcpus in the same node. If
all the conditions above fit, we will wait until all the pages in
scrub list are freed (if waiting time go beyond 20s, we will stop
waiting it.).
This seems to be too restricted at the first glance. We used to only
wait for the free memory size of pinned node is bigger than
required. But as we know HVM memory alloction granularity is 2M. Even
the former condition is satisfied, we still may not find enough
2M-size memory on that node.
Signed-off-by: Ting Zhou <ting.g.zhou@intel.com>
Signed-off-by: Xiaowei Yang <Xiaowei.yang@intel.com>
Move the linux specific labels to osdep where they
belong. Modification on Solaris code ok'd by SUN (Ryan Scott).
Signed-off-by: Christoph Egger <Christoph.Egger@amd.com>
In xend/balloon.py, there's only one place where dom0_start_alloc_mb
is used. Move its initialization to right before its usage.
Signed-off-by: Christoph Egger <Christoph.Egger@amd.com>
I have written a patch to split the current meaning of
"dom0-min-mem = 0" to a new option "enable-dom0-ballooning".
Signed-off-by: Masaki Kanno <kanno.masaki@jp.fujitsu.com>
Signed-off-by: Keir Fraser <keir.fraser@citrix.com>
physical memory constraints.
If users require domain memory size larger than a physical memory
size, we do not need waiting for ballooning, and should cause
xm create command error right away.
Signed-off-by: Masaki Kanno <kanno.masaki@jp.fujitsu.com>
This fixes the case where crashing/restarting a domain can cause dom0 to balloon more than
necessary.
I changed the physinfo dictionary in Python to be in KiB, rather than
MiB, to avoid accumulating ugly rounding errors. I tried to avoid
changing units anywhere else.
Signed-off-by: Charles Coffing <ccoffing@novell.com>
On the ES7000 when Dom0 boots up with all of system memory and you try
to bring up a DomU with more than 2GB of memory, xend times out before
the memory is freed causing the domain not to be created. This patch
increases the timeout depending on the amount of memory that needs to be
freed. It also places a cap on the sleep time so that it does not grow
without a limit. This fixes bug# 650
http://bugzilla.xensource.com/bugzilla/show_bug.cgi?id=3D650
Signed-off-by: Aravindh Puthiyaparambil
<aravindh.puthiyaparambil@unisys.com>
an exception is thrown. The test that decides which exception to throw
is backwards, resulting in strange error messages. The attached patch
fixes the problem.
Signed-off-by: Charles Coffing <ccoffing@novell.com>
occurs in xend. Currently, the parsing is hard-coded; it expects that
the desired number is on the first line. My patch is more robust; it
lets values be retrieved by a label. It also exposes a few functions to
retrieve the current allocation and the target allocation.
By abstracting this a little better, I'll be able to address a few
other issues in subsequent patches. Mostly, this allows for better
error checking and guidance for the user. For example, by exposing
get_dom0_current_alloc(), we can (elsewhere, in a later patch) calculate
how large of a VM could potentially be started. This is useful, as it
lets simple VM-creation GUIs guide the user towards reasonable memory
values for new VMs.
Signed-off-by: Charles Coffing <ccoffing@novell.com>
that there is not sufficient memory available at the moment. Memory may be
about to be freed up by the system after a domain destruction (i.e. the memory
is being scrubbed asynchronously, and will be released soon).
Closes bug #407, bug #429.
Signed-off-by: Ewan Mellor <ewan@xensource.com>
server, where it can be used on reboot and migrate as well as create.
Ballooning bugs may still exist (it is unclear) but this is certainly a good
step in the right direction.
Ignore the memory and maxmem entries in the store for dom0 when restarting.
This means that the value in use at the time becomes the configured target.
This should fix the bug whereby dom0_mem settings on the command line are
being overridden by (older) entries in the store.
Signed-off-by: Ewan Mellor <ewan@xensource.com>
Keir Fraser
Keir Fraser
kfraser@localhost.localdomain
Ewan Mellor
kaf24@firebug.cl.cam.ac.uk
emellor@leeni.uk.xensource.com