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>
'SBDF' format is "[SEG#:]BUS#:DEV#.FUNC#"
ex) 0000:0a:1f.3
Device path format is "HID[:UID]-DEV#.FUNC#[-DEV#.FUNC#[...]]"
ex) PNP0A08:0-2.0-0.0
The command can be executed as follows.
# device_path 0a:1f.3
PNP0A08:0-2.0-0.0
Signed-off-by: Yuji Shimada <shimada-yxb@necst.nec.co.jp>
If you use -MMD -MF then the correct .o filename is written to the
.*.d file as the compiler driver arranges everything. This was done
in 19010:275abe1c5d24 for the hypervisor.
In this patch we do the same elsewhere in the xen-unstable tree,
particularly tools/. Specifically:
* Change tools/Rules.mk to add -MMD -MF ... to CFLAGS and set DEPS.
* Remove -Wp,-MD... from every other Makefile
* Remove setting of DEPS from every other Makefile
* Ensure that every Makefile says -include $(DEPS)
* Ensure that every Makefile's clean target removes $(DEPS)
Some Makefiles were already halfway there, but often for a different
variable name eg PROG_DEP. The variable name is now standardised in
Rules.mk as DEPS.
I have done a test build with this change, on Debian etch.
Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
The Xen tools contain a number of Python extensions written in C. The
C API to Python, used by these extensions, is not stable from one
version of Python to the next.
Our build system uses whatever version of Python is the default on the
build system at that time to build these extensions. However, the
actual scripts such as `xm' use #!/usr/bin/env python which uses
whichever version of Python is the default on the deployment system at
the time of invocation.
If for any reason these two versions of Python are not the same (eg,
because the system is built on one computer and executed on another,
or because the system's gains a more recent Python installation
alongside the original which changes the previous default), warnings
and failures occur.
In this patch I arrange for Python scripts to be installed via a
special wrapper around `install', which determines the build-time
Python version and path and then writes that into the #! line at the
point of `make install' (or `make dist'). (It can also be overridden
by setting PYTHON_PATH.)
Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
lomount is a tool which reads and parses a partition table in a disk
image block device and then uses mount -o ...offset=... to mount it.
This is not an ideal approach. For example, if the intended
filesystem has corrupted metadata the kernel's filesystem driver may
start to write outside of the intended region. This might even be
exploitable in some perverse circumstances.
Nowadays people wanting to do this should use kpartx, which uses
devmapper to create appropriate range mappings. So lomount should be
disabled.
miniterm may well be useful but it is a clone-and-hack of an upstream
project and is currently built but not installed by default, partly
because it doesn't make sense to install on the dom0 which it might be
trying to debug.
It is probably useful to retain these two programs in the source tree
but IMO they should no longer be built by default.
The attached patch does these things:
* CONFIG_LOMOUNT and CONFIG_MINITERM in Config.mk
can enable and disable these programs
* They are disabled by default
* If CONFIG_MINITERM=y it is still built but not installed.
make -C tools/misc/miniterm install will install it.
Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
It predates the current shadow architecture and only performs an explicitly
invalid shadow operation (on itself).
Signed-off-by: Tim Deegan <Tim.Deegan@xensource.com>
advantage that the temporary path manipulation cannot affect the main script,
and that it can be shared with other programs, such as xm-test.
Signed-off-by: Ewan Mellor <ewan@xensource.com>
correct tool to use for hardware perfctr monitoring now.
Also remove unused xc_msr MSR accessor functions from libxenctrl.
Signed-off-by: Keir Fraser <keir@xensource.com>
* Move .PHONY directives next to targets,
this makes them a lot harder to miss
* Add missing .PHONY directives
* Remove nonexistent .PHONY directives
* Hopefully I didn'T miss anything...
Signed-Off-By: Horms <horms@verge.net.au>
Nothing but vnet uses libxutil -- move it there.
Makefile, xc.c, setup.py, configure, configure.in, Makefile.in:
This doesn't use libxutil.
Makefile, Makefile.vnet, Rules.mk:
Move libxutil into vnet since it's only used there.
Many files:
mvdir
Added the mbootpack tool, which packages multiboot boot files and
disguises them as a linux bzImage. Useful for booting Xen using
pxelinux, or another linux-only bootloader.
Signed-off-by: Tim Deegan <Tim.Deegan@cl.cam.ac.uk>
[PATCH] add-build.patch
Add build targets to all makefiles. Debian does builds as non-root, so
it's better to do as much as possible before requiring root privs.
Signed-off-by: Adam Heath <doogie@brainfood.com>
Name: tools-misc-TARGETS.patch
Description: Split compile/link stages
distcc behaves much better when you compile and link in 2 separate steps.
Plus, this is a more standard way of doing things.
Signed-off-by: Adam Heath <doogie@brainfood.com>
Signed-off-by: ian.pratt@cl.cam.ac.uk
Description: use DESTDIR correctly
Standard makefiles always attempt to install to the root(/). Setting
DESTDIR is the normal way to install to an alternative location.
Setting prefix has the possibility of breaking programs, as the prefix
may have been embedded inside a compiled binary.
From: Adam Heath <doogie@brainfood.com>
Signed-off-by: ian.pratt@cl.cam.ac.uk
Description: use INSTALL everywhere
Use install(by way of INSTALL variables) to create directories, install
programs, and install data files.
From: Adam Heath <doogie@brainfood.com>
Signed-off-by: ian.pratt@cl.cam.ac.uk
Clean up public XenLinux header files. Now accessible from userspace as
#include <xen/linux...>
Got rid of the linux-xen-sparse symlink as it's no longer needed.
