xen-project/xen
1
0 Fork 0
mirror of https://github.com/xen-project/xen.git synced 2026-10-28 02:01:24 +01:00
Code Issues Activity

bitkeeper revision 1.1159.137.1 (41811b328SwfN4BTxZsoMM-iGa8evQ)

Browse Source 
Delete some unused tools, lots of docs updates.
This commit is contained in:
mwilli2@equilibrium.research committed 2004-10-28 16:15:46 +00:00
1 parent 57ba232013
commit 60eba9b0d2
10 files changed
+231 -1858
Download Patch File Download Diff File Expand all files Collapse all files

No files matched your search

.rootkeys
+1 -5
View File
@@ -5,7 +5,6 @@
4177dbbfqsi01p2zgZa0geUOgScONw COPYING
3eb788d6Kleck_Cut0ouGneviGzliQ Makefile
3f5ef5a24IaQasQE2tyMxrfxskMmvw README
3f5ef5a2l4kfBYSQTUaOyyD76WROZQ README.CD
3f69d8abYB1vMyD_QVDvzxy5Zscf1A TODO
3f9e7d53iC47UnlfORp9iC1vai6kWw docs/Makefile
3f9e7d60PWZJeVh5xdnk0nLUdxlqEA docs/figs/xenlogo.eps
@@ -354,15 +353,12 @@
40c9c469kT0H9COWzA4XzPBjWK0WsA tools/misc/netfix
4022a73cEKvrYe_DVZW2JlAxobg9wg tools/misc/nsplitd/Makefile
4022a73cKms4Oq030x2JBzUB426lAQ tools/misc/nsplitd/nsplitd.c
3f870808_8aFBAcZbWiWGdgrGQyIEw tools/misc/p4perf.h
4113d1afyPjO8m8-9E1pVBDHzGe1jQ tools/misc/setdomainmaxmem
3f5ef5a2ir1kVAthS14Dc5QIRCEFWg tools/misc/xen-clone
3f5ef5a2dTZP0nnsFoeq2jRf3mWDDg tools/misc/xen-clone.README
3f870808zS6T6iFhqYPGelroZlVfGQ tools/misc/xen_cpuperf.c
405eedf6_nnNhFQ1I85lhCkLK6jFGA tools/misc/xencons
40c9c4697z76HDfkCLdMhmaEwzFoNQ tools/misc/xend
4107986eMWVdBoz4tXYoOscpN_BCYg tools/misc/xensv
4056f5155QYZdsk-1fLdjsZPFTnlhg tools/misc/xensymoops.py
4056f5155QYZdsk-1fLdjsZPFTnlhg tools/misc/xensymoops
40cf2937dqM1jWW87O5OoOYND8leuA tools/misc/xm
40c9c468icGyC5RAF1bRKsCXPDCvsA tools/python/Makefile
40ffc44dOwe1CcYXGCkYHdG_NxcccA tools/python/logging/logging-0.4.9.2/PKG-INFO
README
+10 -198
View File
@@ -8,9 +8,9 @@ __ __ ____ ___
###############################
University of Cambridge Computer Laboratory
28 Aug 2004
28 Oct 2004
http://www.cl.cam.ac.uk/netos/xen
http://www.cl.cam.ac.uk/netos/xen/
About the Xen Virtual Machine Monitor
=====================================
@@ -19,201 +19,13 @@ About the Xen Virtual Machine Monitor
Systems Research Group of the University of Cambridge Computer
Laboratory, as part of the UK-EPSRC funded XenoServers project.
The XenoServers project aims to provide a "public infrastructure for
global distributed computing", and Xen plays a key part in that,
allowing us to efficiently partition a single machine to enable
multiple independent clients to run their operating systems and
applications in an environment providing protection, resource
isolation and accounting. The project web page contains further
information along with pointers to papers and technical reports:
http://www.cl.cam.ac.uk/xeno
Xen has since grown into a project in its own right, enabling us to
investigate interesting research issues regarding the best techniques
for virtualizing resources such as the CPU, memory, disk and network.
The project has been bolstered by support from Intel Research
Cambridge, and HP Labs, who are now working closely with us. We're
also in receipt of support from Microsoft Research Cambridge to port
Windows XP to run on Xen.
Xen enables multiple operating system images to execute concurrently
on the same hardware with very low performance overhead --- much lower
than commercial offerings for the same x86 platform.
This is achieved by requiring OSs to be specifically ported to run on
Xen, rather than allowing unmodified OS images to be used. Crucially,
only the OS needs to be changed -- all of the user-level application
binaries, libraries etc can run unmodified. Hence the modified OS
kernel can typically just be dropped into any existing OS distribution
or installation.
Xen currently runs on the x86 architecture, but could in principle be
ported to others. In fact, it would have been rather easier to write
Xen for pretty much any other architecture as x86 is particularly
tricky to handle. A good description of Xen's design, implementation
and performance is contained in our October 2003 SOSP paper, available
at http://www.cl.cam.ac.uk/netos/papers/2003-xensosp.pdf
[update: work to port Xen to x86_64 and IA64 is underway]
Five different operating systems have been ported to run on Xen:
Linux 2.4/2.6, Windows XP, NetBSD, FreeBSD and Plan 9.
The Linux 2.4 port (currently Linux 2.4.26) works very well -- we
regularly use it to host complex applications such as PostgreSQL,
Apache, BK servers etc. It runs every user-space applications we've
tried. We refer to our version of Linux ported to run on Xen as
"XenLinux", although really it's just standard Linux ported to a new
virtual CPU architecture that we call xen-x86.
NetBSD has been ported to Xen by Christian Limpach, and will hopefully
soon become part of the standard release. Work on a FreeBSD port has
been started by Kip Macy, and we hope to see this complete for the 2.0
release. Ron Minnich has been working on Plan 9.
The Windows XP port is nearly finished. It's running user space
applications and is generally in pretty good shape thanks to some hard
work by a team over the summer. Of course, there are issues with
releasing this code to others. We should be able to release the
source and binaries to anyone that has signed the Microsoft academic
source license, which these days has very reasonable terms. We are in
discussions with Microsoft about the possibility of being able to make
binary releases to a larger user community. Obviously, there are
issues with product activation in this environment which need to be
thought through.
So, for the moment, you only get to run Linux 2.4/2.6 and NetBSD on
Xen, but we hope this will change before too long. Even running
multiple copies of the same OS can be very useful, as it provides a
means of containing faults to one OS image, and also for providing
performance isolation between the various OS, enabling you to either
restrict, or reserve resources for, particular VM instances.
It's also useful for development -- each version of Linux can have
different patches applied, enabling different kernels to be tried
out. For example, the "vservers" patch used by PlanetLab applies
cleanly to our ported version of Linux.
We've successfully booted over 128 copies of Linux on the same machine
(a dual CPU hyperthreaded Xeon box) but we imagine that it would be
more normal to use some smaller number, perhaps 10-20.
A common question is "how many virtual machines can I run on hardware
xyz?". The answer is very application dependent, but the rule of thumb
is that you should expect to be able to run the same workload under
multiple guest OSes that you could run under a single Linux instance,
with an additional overhead of a few MB per OS instance.
One key feature in this new release of Xen is `live migration'. This
enables virtual machines instances to be dynamically moved between
physical Xen machines, with typical downtimes of just a few tens of
milliseconds. This is really useful for admins that want to take a
node down for maintenance, or to load balance a large number of
virtual machines across a cluster.
Hardware support
================
Xen is intended to be run on server-class machines, and the current
list of supported hardware very much reflects this, avoiding the need
for us to write drivers for "legacy" hardware. It is likely that some
desktop chipsets will fail to work properly with the default Xen
configuration: specifying 'noacpi' or 'ignorebiostables' when booting
Xen may help in these cases.
Xen requires a "P6" or newer processor (e.g. Pentium Pro, Celeron,
Pentium II, Pentium III, Pentium IV, Xeon, AMD Athlon, AMD Duron).
Multiprocessor machines are supported, and we also have basic support
for HyperThreading (SMT), although this remains a topic for ongoing
research. We're also working on an AMD x86_64 port (though Xen should
run on Opterons in 32-bit mode just fine).
Xen can currently use up to 4GB of memory. It's possible for x86
machines to address more than that (64GB), but it requires using a
different page table format (3-level rather than 2-level) that we
currently don't support. Adding 3-level PAE support wouldn't be
difficult, but we'd also need to add support to all the guest
OSs. Volunteers welcome!
In contrast to previous Xen versions, in Xen 2.0 device drivers run
within a privileged guest OS rather than within Xen itself. This means
that we should be compatible with the full set of device hardware
supported by Linux. The default XenLinux build contains support for
relatively modern server-class network and disk hardware, but you can
add suppport for other hardware by configuring your XenLinux kernel in
the normal way (e.g. "make xconfig").
Building Xen and XenLinux
=========================
The public master BK repository for the 2.0 release lives at:
bk://xen.bkbits.net/xen-2.0.bk
To fetch a local copy, install the BitKeeper tools, then run:
'bk clone bk://xen.bkbits.net/xen-2.0.bk'
You can do a complete build of Xen, the control tools, and the
XenLinux kernel images with "make world". This can take 10 minutes
even on a fast machine. If you're on an SMP machine you may wish to
give the '-j4' argument to make to get a parallel build. All of the
files that are built are placed under the ./install directory. You
can then install everything to the standard system directories
(e.g. /boot, /usr/bin, /usr/lib/python/ etc) by typing "make install".
Take a look in install/boot/:
install/boot/xen.gz The Xen 'kernel' (formerly image.gz)
install/boot/vmlinuz-2.4.27-xen0 Domain 0 XenLinux kernel (xenolinux.gz)
install/boot/vmlinuz-2.4.27-xenU Unprivileged XenLinux kernel
The difference between the two Linux kernels that are built is
due to the configuration file used for each. The "U" suffixed
unprivileged version doesn't contain any of the physical hardware
device drivers, so is 30% smaller and hence may be preferred for
your non-privileged domains.
The install/boot directory will also contain the config files
used for building the XenLinux kernels, and also versions of Xen
and XenLinux kernels that contain debug symbols (xen-syms and
vmlinux-syms-2.4.27-xen0) which are essential for interpreting crash
dumps.
Inspect the Makefile if you want to see what goes on during a
build. Building Xen and the tools is straightforward, but XenLinux is
more complicated. The makefile needs a 'pristine' linux kernel tree
which it will then add the Xen architecture files to. You can tell the
makefile the location of the appropriate linux compressed tar file by
setting the LINUX_SRC environment variable
(e.g. "LINUX_SRC=/tmp/linux-2.4.27.tar.gz make world") or by placing
the tar file somewhere in the search path of LINUX_SRC_PATH which
defaults to ".:..". If the makefile can't find a suitable kernel tar
file it attempts to download it from kernel.org, but this won't work
if you're behind a firewall.
After untaring the pristine kernel tree, the makefile uses the
'mkbuildtree' script to add the Xen patches the kernel. "make world"
then build two different XenLinux images, one with a "-xen0" extension
which contains hardware device drivers and is intended to be used in
the first virtual machine ("domain 0"), and one with a "-xenU"
extension that just contains virtual-device drivers. The latter can be
used for all non hardware privileged domains, and is substantially
smaller than the other kernel with its selection of hardware drivers.
If you don't want to use bitkeeper to download the source, you can
download prebuilt binaries and src tar balls from the project
downloads page: http://www.cl.cam.ac.uk/netos/xen/downloads/
Using the domain control tools
==============================
Before starting domains you'll need to start the node management
daemon: "xend start".
The primary tool for starting and controlling domains is "xm".
"xm help <cmd>" will tell you how to use it.
README.CD contains some example invocations.
Further documentation is in docs/ (e.g., docs/Xen-HOWTO), and also in
Xen 2.0 offers excellent performance, hardware support and enterprise
grade features such as live migration. Linux 2.6, 2.4 and NetBSD 2.0
are already available for Xen, with more operating system ports on the
way.
Xen is Free Open Source Software, released under the GNU GPL.
For full documentation, see the Xen User Manual in docs/user.pdf
(after running make -C docs) or the Documentation page on the Xen
website.
README.CD
-737
View File
@@ -1,737 +0,0 @@
###############################
__ __ ____ ___
\ \/ /___ _ __ |___ \ / _ \
\ // _ \ '_ \ __) || | | |
/ \ __/ | | | / __/ | |_| |
/_/\_\___|_| |_| |_____(_)___/
###############################
XenDemoCD 2.0
University of Cambridge Computer Laboratory
28 Aug 2004
http://www.cl.cam.ac.uk/netos/xen
Welcome to the Xen Demo CD!
Executive Summary
=================
This CD is a standalone demo of the Xen Virtual Machine Monitor (VMM),
Linux-2.4 and Linux-2.6 OS port (Xenlinux). It runs entirely off the
CD, without requiring hard disk installation. This is achieved using a
RAM disk to store mutable file system data while using the CD for
everything else. The CD can also be used for installing Xen/Xenlinux
to disk, and includes a source code snapshot along with all of the
tools required to build it.
Booting the CD
==============
It should be possible to get Xen working with any relatively modern
hardware supported by standard Linux. However, the version of XenLinux
built for the DemoCD is fairly h/w specific. If you need other
hardware, you'll have to configure and build your own xenlinux kernel.
Xen does require an 'i686'-class CPU or newer, so won't work on 486's
or plain Pentiums.
We have compiled in drivers for the following hardware:
CPU: Pentium Pro/II/III/IV/Xeon, Athlon (i.e. P6 or newer) SMP supported
IDE: Intel PIIX chipset, others will be PIO only (slow)
SCSI: Adaptec / Dell PERC Raid (aacraid), fusion MPT, megaraid, Adaptec aic7xxx
Net: Recommended: Intel e1000, Broadcom BCM57xx (tg3), 3c905 (3c59x)
Also supported: pcnet32, Intel e100, tulip
Because of the demo CD's use of RAM disks, make sure you have plenty
of RAM (256MB+).
To try out the Demo, boot from CD (you may need to change your BIOS
configuration to do this), then select one of the four boot options
from the Grub menu:
Xen / linux-2.4.27
Xen / linux-2.4.27 using cmdline IP configuration
Xen / linux-2.4.27 in "safe mode"
linux-2.4.22
The last option is a plain linux kernel that runs on the bare machine,
and is included simply to help diagnose driver compatibility
problems. The "safe mode" boot option might be useful if you're having
problems getting Xen to work with your hardware, as it disables various
features such as SMP, and enables some debugging.
If you are going for a command line IP config, hit "e" at
the grub menu, then edit the "ip=" parameters to reflect your setup
e.g. "ip=<ipaddr>::<gateway>:<netmask>::eth0:off". It shouldn't be
necessary to set either the nfs server or hostname
parameters. Alternatively, once Xenlinux has booted you can login and
setup networking with 'dhclient' or 'ifconfig' and 'route' in the
normal way.
To make things easier for yourself, it's worth trying to arrange for an
IP address which is the first in a sequential range of free IP
addresses. It's useful to give each VM instance its own public IP
address (though it is possible to do NAT or use private addresses),
and the configuration files on the CD allocate IP addresses
sequentially for subsequent domains unless told otherwise.
After selecting the kernel to boot, stand back and watch Xen boot,
closely followed by "domain 0" running the Xenlinux kernel. The boot
messages can also sent to the serial line by specifying the baud rate
on the Xen cmdline (e.g., 'com1=9600,8n1'); this can be very useful
for debugging should anything important scroll off the screen. Xen's
startup messages will look quite familiar as much of the hardware
initialisation (SMP boot, apic setup) and device drivers are derived
from Linux.
If everything is well, you should see the linux rc scripts start a
bunch of standard services including sshd. Login on the console or
via ssh::
username: user root
password: xendemo xendemo
Once logged in, it should look just like any regular linux box. All
the usual tools and commands should work as per usual. However,
because of the poor random access performance of CD drives, the
machine will feel very slugish, and you may run out of memory if you
make significant modifications to the ramfs filesystem -- for the full
experience, install a Xen and Xenlinux image on you hard drive :-)
You can configure networking, either with 'dhclient' or manually via
'ifconfig' and 'route', remembering to edit /etc/resolv.conf if you
want DNS to work.
You can start an X server with 'startx'. It defaults to a conservative
1024x768, but you can edit the script for higher resoloutions. The CD
contains a load of standard software. You should be able to start
Apache, PostgreSQL, Mozilla etc in the normal way, but because
everything is running off CD the performance will be very sluggish and
you may run out of memory for the 'tmpfs' file system. You may wish
to go ahead and install Xen/Xenlinux on your hard drive, either
dropping Xen and the Xenlinux kernel down onto a pre-existing Linux
distribution, or using the file systems from the CD (which are based
on RH9). See the installation instructions later in this document.
If your video card requires 'agpgart' then it unfortunately won't yet
work with Xen, and you'll only be able to configure a VGA X
server. We're working on a fix for this for the next release.
If you want to browse the Xen / Xenlinux source, it's all located
under /usr/local/src/xen-2.0.bk, complete with BitKeeper
repository. We've also included source code and configuration
information for the various benchmarks we used in the SOSP paper.
Starting other domains
======================
The first thing you need to do is to start the "xend" control daemon
with "xend start". You may wish to add an appropriate link to xend in
you /etc/rcX.d directory e.g. "ln -sf ../init.d/xend S97xend"
If you're not intending to configure the new domain with an IP address
on your LAN, then you'll probably want to use NAT. The
'xen_nat_enable' installs a few useful iptables rules into domain0 to
enable NAT. [NB: We plan to support RSIP in future]
Xen has a management interface that can be manipulated from domain0 to
create new domains, control their CPU, network and memory resource
allocations, allocate IP addresses, grant access to disk partitions,
and suspend/resume domains to files, etc. The management interface is
implemented as a set of library functions (implemented in C) for which
there are Python language bindings.
We have developed a simple set of example python tools for
manipulating the interface, with the intention that more sophisticated
high-level management tools will be developed in due course. Within
the source repository the tools live in tools/examples/ but are
installed in /usr/local/bin/ on the CD.
Starting a new domain is achieved using the command 'xm create' which
allocates resources to a new domain, populates it with a kernel image
(and optionally a ramdisk) and then starts it.
It parses a configuration file written in the Python language, the
default location of which is "/etc/xc/defaults", but this may be
overridden with the "-f" option. For the Demo CD, the defaults file
will cause domains to be created with ram-based root file systems, and
mount their /usr partition from the CD, just like domain0. (If you are
writing your own config file, the "example" script may be a better
starting point)
Variables can be initialised and passed into configuration files. Some
of these may be compulsory, others optional.
The 'defaults' file on the CD requires the 'ip' variable to be set to
tell Xen what IP address(es) should be routed to this domain. Xen
will route packets to the domain if they bear one of these addresses
as a destination address, and will also ensure that packets sent from
the domain contain one of the addresses as a source address (to
prevent spoofing). If multiple IP addresses are to be assigned to a
domain they can be listed in a comma separated list (with no
whitespace).
The 'mem' variable can be used to change the default memory allocation
of 64MB. For example to start a domain with two IP addresses and
72MB:
xm create ip=128.23.45.34,169.254.1.1mem=72
When invoked with the '-n' option 'xm create' will do a dry run
and just print out what resources and configuration the domain will
have e.g.:
[root@xendemo]# xm create -n ip=commando-1.xeno,169.254.2.3 mem=100
Parsing config file 'defaults'
VM image : "/boot/xenlinux.gz"
VM ramdisk : "/boot/initrd.gz"
VM memory (MB) : "100"
VM IP address(es) : "128.232.38.51:169.254.2.3"
VM block device(s) : "phy:cdrom,hdd,r"
VM cmdline : "ip=128.232.38.51:169.254.1.0:128.232.32.1:255.255.240.0::eth0:off root=/dev/ram0 rw init=/linuxrc 4 LOCALIP=169.254.2.3"
xm create will print the local TCP port to which you should
connect to perform console I/O. A suitable console client is provided
by the Python module xenctl.console_client: running this module from
the command line with <host> and <port> parameters will start a
terminal session. This module is also installed as /usr/bin/xencons,
from a copy in tools/misc/xencons. An alternative to manually running
a terminal client is to specify '-c' to xm create, or add
'auto_console=True' to the defaults file. This will cause
'xm create' to automatically become the console terminal after
starting the domain.
The 169.254.x.x network is special in that it is the 'link local'
subnet, and is isolated from the external network and hence can only
be used for communication between virtual machines. By convention, we
usually give each domain a link local address. The startup scripts on
the CD have been modified to accept a LINKLOCAL= parameter on the
kernel command line and initialise an IP alias accordingly (see
/etc/sysinit/network-scripts/ifcfg-eth0).
Linux only allows one IP address to be specified on the kernel command
line, so if you specify multiple IP addresses you'll need to configure
the new Linux VM with the other addresses manually (using ifconfig)
having logged in.
If you inspect the 'defaults' config script you'll see that the new
domain was started with a '4' on the kernel command line to tell
'init' to go to runlevel 4 rather than the default of 3 used by
domain0. This is done simply to suppress a bunch of harmless error
messages that would otherwise occur when the new (unprivileged) domain
tried to access physical hardware resources to try setting the
hwclock, system font, run gpm etc.
After it's booted, you should be able to ssh into your new domain from
domain0 using the link local 19.254.x.x address you assigned. If you
assigned a further IP address you should be able to ssh in using that
address too. If you ran the xen_enable_nat script, a bunch of port
redirects have been installed to enable you to ssh in to other domains
remotely even if you didn't assign an externally routeable address.
To access the new virtual machine remotely, use:
ssh -p2201 root@IP.address.Of.Domain0 # use 2202 for domain 2 etc.
You can manipulate running domains using the xm tool.
Invoking it without arguments prints some usage information.
To see what domains are running, run 'xm list'. Using the
tool you can change scheduling parameters, pause a domain, send it a
shutdown request, or blow it away with the 'destroy' command. You can
even suspend it to disk (but you probably won't have enough memory to
do the latter if you're running off the demo CD).
To find usage information for xm, run the script with no arguments or
with the 'help' argument. To get help on a particular xm command, use
'xm cmdname help'.
Troubleshooting Problems
========================
If you have problems booting Xen, there are a number of boot parameters
that may be able to help diagnose problems:
ignorebiostables Disable parsing of BIOS-supplied tables. This may
help with some chipsets that aren't fully supported
by Xen. If you specify this option then ACPI tables are
also ignored, and SMP support is disabled.
noreboot Don't reboot the machine automatically on errors.
This is useful to catch debug output if you aren't
catching console messages via the serial line.
nosmp Disable SMP support.
This option is implied by 'ignorebiostables'.
noacpi Disable ACPI tables, which confuse Xen on some chipsets.
This option is implied by 'ignorebiostables'.
watchdog Enable NMI watchdog which can report certain failures.
noht Disable Hyperthreading.
badpage=<page number>[,<page number>]*
Specify a list of pages not to be allocated for use
because they contain bad bytes. For example, if your
memory tester says that byte 0x12345678 is bad, you would
place 'badpage=0x12345' on Xen's command line (i.e., the
last three digits of the byte address are not included!).
com1=<baud>,DPS[,<io_base>,<irq>]
com2=<baud>,DPS[,<io_base>,<irq>]
Xen supports up to two 16550-compatible serial ports.
For example: 'com1=9600,8n1,0x408,5' maps COM1 to a
9600-baud port, 8 data bits, no parity, 1 stop bit,
I/O port base 0x408, IRQ 5.
If the I/O base and IRQ are standard (com1:0x3f8,4;
com2:0x2f8,3) then they need not be specified.
console=<specifier list>
Specify the destination for Xen console I/O.
This is a comma-separated list of, for example:
vga: use VGA console and allow keyboard input
com1: use serial port com1
com2H: use serial port com2. Transmitted chars will
have the MSB set. Received chars must have
MSB set.
com2L: use serial port com2. Transmitted chars will
have the MSB cleared. Received chars must
have MSB cleared.
The latter two examples allow a single port to be
shared by two subsystems (eg. console and
debugger). Sharing is controlled by MSB of each
transmitted/received character.
[NB. Default for this option is 'com1,vga']
conswitch=<switch-char><auto-switch-char>
Specify how to switch serial-console input between
Xen and DOM0. The required sequence is CTRL-<switch_char>
pressed three times. Specifying '`' disables switching.
The <auto-switch-char> specifies whether Xen should
auto-switch input to DOM0 when it boots -- if it is 'x'
then auto-switching is disabled. Any other value, or
omitting the character, enables auto-switching.
[NB. Default for this option is 'a']
nmi=<nmi-error-behaviour>
Specify what to do with an NMI parity or I/O error.
'nmi=fatal': Xen prints a diagnostic and then hangs.
'nmi=dom0': Inform DOM0 of the NMI.
'nmi=ignore': Ignore the NMI.
[NB. Default is 'dom0' ('fatal' for debug builds).]
dom0_mem=xxx Set the initial amount of memory for domain0.
pdb=xxx Enable the pervasive debugger. See docs/pdb.txt
xxx defines how the gdb stub will communicate:
com1 use com1
com1H use com1 (with high bit set)
com2 use on com2
com2H use com2 (with high bit set)
It's probably a good idea to join the Xen developer's mailing list on
Sourceforge: http://lists.sourceforge.net/lists/listinfo/xen-devel
About The Xen Demo CD
=====================
The purpose of the Demo CD is to distribute a snapshot of Xen's
source, and simultaneously provide a convenient means for enabling
people to get experience playing with Xen without needing to install
it on their hard drive. If you decide to install Xen/Xenlinux you can
do so simply by following the installation instructions below -- which
essentially involves copying the contents of the CD on to a suitably
formated disk partition, and then installing or updating the Grub
bootloader.
This is a bootable CD that loads Xen, and then a Linux 2.4.27 OS image
ported to run on Xen. The CD contains a copy of a file system based on
the RedHat 9 distribution that is able to run directly off the CD
("live ISO"), using a "tmpfs" RAM-based file system for root (/etc
/var etc). Changes you make to the tmpfs will obviously not be
persistent across reboots!
Because of the use of a RAM-based file system for root, you'll need
plenty of memory to run this CD -- something like 96MB per VM. This is
not a restriction of Xen : once you've installed Xen, Xenlinux and
the file system images on your hard drive you'll find you can boot VMs
in just a few MBs.
The CD contains a snapshot of the Xen and Xenlinux code base that we
believe to be pretty stable, but lacks some of the features that are
currently still work in progress e.g. OS suspend/resume to disk, and
various memory management enhancements to provide fast inter-OS
communication and sharing of memory pages between OSs. We'll release
newer snapshots as required, making use of a BitKeeper repository
hosted on http://xen.bkbits.net (follow instructions from the project
home page). We're obviously grateful to receive any bug fixes or
other code you can contribute. We suggest you join the
xen-devel@lists.sourceforge.net mailing list.
Installing from the CD
======================
If you're installing Xen/Xenlinux onto an existing linux file system
distribution, just copy the Xen VMM (/boot/image.gz) and Xenlinux
kernels (/boot/xenlinux.gz), then modify the Grub config
(/boot/grub/menu.lst or /boot/grub/grub.conf) on the target system.
It should work on pretty much any distribution.
Xen is a "multiboot" standard boot image. Despite being a 'standard',
few boot loaders actually support it. The only two we know of are
Grub, and our modified version of linux kexec (for booting off a
XenoBoot CD -- PlanetLab have adopted the same boot CD approach).
If you need to install grub on your system, you can do so either by
building the Grub source tree
/usr/local/src/grub-0.93-iso9660-splashimage or by copying over all
the files in /boot/grub and then running /sbin/grub and following the
usual grub documentation. You'll then need to edit the Grub
config file.
A typical Grub menu option might look like:
title Xen 2.0 / Xenlinux 2.4.27
kernel /boot/xen.gz dom0_mem=131072 com1=115200 noht watchdog
module /boot/vmlinuz-2.4.27-xen0 root=/dev/sda4 ro
The first line specifies which Xen image to use, and what command line
arguments to pass to Xen. In this case we set the maximum amount of
memory to allocate to domain0, and enable serial I/O on COM1 at 115200
baud. We could also disable smp support (nosmp) or disable
hyper-threading support (noht).
The second line specifies which xenlinux image to use, and the
standard linux command line arguments to pass to the kernel. In this
case, we're configuring the root partition and stating that it should
initially be mounted read-only (normal practice).
If we were booting with an initial ram disk (initrd), then this would
require a second "module" line.
Installing the Xen tools and source
===================================
The tools and source live in the /usr/local/src/xen-2.0.bk directory on
the CD (and may also be downloaded from the project downloads
page). You'll need to copy them to some mutable storage before using
them.
If you have the BitKeeper BK tools installed you can check the
repository is up to date by cd'ing into the xeno-2.0.bk directory and
typing 'bk pull' (assuming you have an Internet connection).
You can rebuild Xen, the tools and XenLinux by typing 'make
world'. You can install them to the standard directories with 'make
install', or into the ./install subtree with 'make dist'.
Modifying xc_mycreatelinuxdom1.py
=================================
xc_mycreatelinuxdom1.py.py can be used to set the new kernel's command line,
and hence determine what it uses as a root file system, etc. Although
the default is to boot in the same manner that domain0 did (using the
RAM-based file system for root and the CD for /usr) it's possible to
configure any of the following possibilities, for example:
* initrd=/boot/initrd init=/linuxrc
boot using an initial ram disk, executing /linuxrc (as per this CD)
* root=/dev/hda3 ro
boot using a standard hard disk partition as root
!!! remember to grant access in createlinuxdom.py.
* root=/dev/xvda1 ro
boot using a pre-configured 'virtual block device' that will be
attached to a virtual disk that previously has had a file system
installed on it.
* root=/dev/nfs nfsroot=/path/on/server ip=<blah_including server_IP>
Boot using an NFS mounted root file system. This could be from a
remote NFS server, or from an NFS server running in another
domain. The latter is rather a useful option.
A typical setup might be to allocate a standard disk partition for
each domain and populate it with files. To save space, having a shared
read-only usr partition might make sense.
Block devices should only be shared between domains in a read-only
fashion otherwise the linux kernels will obviously get very confused
as the file system structure may change underneath them (having the
same partition mounted rw twice is a sure fire way to cause
irreparable damage)! If you want read-write sharing, export the
directory to other domains via NFS from domain0.
Installing the file systems from the CD
=======================================
If you haven't got an existing Linux installation onto which you can
just drop down the Xen and Xenlinux images, then the file systems on
the CD provide a quick way of doing an install. However, you would be
better off in the long run doing a proper install of your preferred
distro and installing Xen onto that, rather than just doing the hack
described below:
Choose one or two partitions, depending on whether you want a separate
/usr or not. Make file systems on it/them e.g.:
mkfs -t ext3 /dev/hda3
[or mkfs -t ext2 /dev/hda3 && tune2fs -j /dev/hda3 if using an old
version of mkfs]
Next, mount the file system(s) e.g.:
mkdir /mnt/root && mount /dev/hda3 /mnt/root
[mkdir /mnt/usr && mount /dev/hda4 /mnt/usr]
To install the root file system, simply untar /usr/XenDemoCD/root.tar.gz:
cd /mnt/root && tar -zxpf /usr/XenDemoCD/root.tar.gz
You'll need to edit /mnt/root/etc/fstab to reflect your file system
configuration. Changing the password file (etc/shadow) is probably a
good idea too.
To install the usr file system, copy the file system from CD on /usr,
though leaving out the "XenDemoCD" and "boot" directories:
cd /usr && cp -a X11R6 etc java libexec root src bin dict kerberos local sbin tmp doc include lib man share /mnt/usr
If you intend to boot off these file systems (i.e. use them for
domain 0), then you probably want to copy the /usr/boot directory on
the cd over the top of the current symlink to /boot on your root
filesystem (after deleting the current symlink) i.e.:
cd /mnt/root ; rm boot ; cp -a /usr/boot .
The XenDemoCD directory is only useful if you want to build your own
version of the XenDemoCD (see below).
Debugging
=========
Xen has a set of debugging features that can be useful to try and
figure out what's going on. Hit 'h' on the serial line (if you
specified a baud rate on the Xen command line) or ScrollLock-h on the
keyboard to get a list of supported commands.
If you have a crash you'll likely get a crash dump containing an EIP
(PC) which, along with an 'objdump -d image', can be useful in
figuring out what's happened. Debug a Xenlinux image just as you
would any other Linux kernel.
We supply a handy debug terminal program which you can find in
/usr/local/src/xen-2.0.bk/tools/misc/miniterm/
This should be built and executed on another machine that is connected
via a null modem cable. Documentation is included.
Alternatively, if the Xen machine is connected to a serial-port server
then we supply a dumb TCP terminal client:
'tools/xenctl/lib/console_client.py <server host> <server port>'
Installing Xen / Xenlinux on a RedHat distribution
===================================================
When using Xen / Xenlinux on a standard Linux distribution there are
a couple of things to watch out for:
The first Linux VM that is started when Xen boots start (Domain 0) is
given direct access to the graphics card, so it may use it as a
console. Other domains don't have ttyN consoles, so attempts to run a
'mingetty' against them will fail, generating periodic warning
messages from 'init' about services respawning too fast. They should
work for domain0 just fine.
IMPORTANT: To prevent warning messages when running RH9 you'll need to
remove ttyN from /etc/inittab for domains>0. Due to a bug in the RH9
/etc/rc.sysinit script #'ing the lines out of /etc/inittab won't work
as it ignores the '#' and tries to access them anyway.
Every Xenlinux instance owns a bidirectional 'virtual console'.
The device node to which this console is attached can be configured
by specifying 'xencons=' on the OS command line:
'xencons=off' --> disable virtual console
'xencons=tty' --> attach console to /dev/tty1 (tty0 at boot-time)
'xencons=ttyS' --> attach console to /dev/ttyS0
The default is to attach to /dev/tty1, and also to create dummy
devices for /dev/tty2-63 to avoid warnings from many standard distro
startup scripts. The exception is domain 0, which by default attaches
to /dev/ttyS0.
Note that, because domains>0 don't have any privileged access at all,
certain commands in the default boot sequence will fail e.g. attempts
to update the hwclock, change the console font, update the keytable
map, start apmd (power management), or gpm (mouse cursor). Either
ignore the errors, or remove them from the startup scripts. Deleting
the following links are a good start: S24pcmcia S09isdn S17keytable
S26apmd S85gpm
If you want to use a single root file system that works cleanly for
domain0 and domains>0, one trick is to use different 'init' run
levels. For example, on the Xen Demo CD we use run level 3 for domain
0, and run level 4 for domains>0. This enables different startup
scripts to be run in depending on the run level number passed on the
kernel command line.
Xenlinux kernels can be built to use runtime loadable modules just
like normal linux kernels. Modules should be installed under
/lib/modules in the normal way.
If there's some kernel feature that hasn't been built into our default
kernel, there's a pretty good change that if its a non-hardware
related option you'll just be able to enable it and rebuild. If its
not on the xconfig menu, hack the arch/xen/config.in to put the menu
back in.
If you're going to use the link local 169.254.1.x addresses to
communicate between VMs, there are a couple of other issues to watch
out for. RH9 appears to have a bug where by default it configures the
loopback interface with a 169.254 address, which stops it working
properly on eth0 for communicating with other domains.
This utterly daft RH9 behaviour can be stopped by appending
"NOZEROCONF=yes" to /etc/sysconfig/networking-scripts/ifcfg-lo
If you're going to use NFS root files systems mounted either from an
external server or from domain0 there are a couple of other gotchas.
The default /etc/sysconfig/iptables rules block NFS, so part way
through the boot sequence things will suddenly go dead.
If you're planning on having a separate NFS /usr partition, the RH9
boot scripts don't make life easy, as they attempt to mount NFS file
systems way to late in the boot process. The easiest way I found to do
this was to have a '/linuxrc' script run ahead of /sbin/init that
mounts /usr:
#!/bin/bash
/sbin/ipconfig lo 127.0.0.1
/sbin/portmap
/bin/mount /usr
exec /sbin/init "$@" <>/dev/console 2>&1
The one slight complication with the above is that /sbib/portmap is
dynamically linked against /usr/lib/libwrap.so.0 Since this is in
/usr, it won't work. I solved this by copying the file (and link)
below the /usr mount point, and just let the file be 'covered' when
the mount happens.
In some installations, where a shared read-only /usr is being used, it
may be desirable to move other large directories over into the
read-only /usr. For example, on the XenDemoCD we replace /bin /lib and
/sbin with links into /usr/root/bin /usr/root/lib and /usr/root/sbin
respectively. This creates other problems for running the /linuxrc
script, requiring bash, portmap, mount, ifconfig, and a handful of
other shared libraries to be copied below the mount point. I guess I
should have written a little statically linked C program...
Description of how the XenDemoCD boots
======================================
1. Grub is used to load Xen, a Xenlinux kernel, and an initrd (initial
ram disk). [The source of the version of Grub used is in /usr/local/src]
2. the init=/linuxrc command line causes linux to execute /linuxrc in
the initrd.
3. the /linuxrc file attempts to mount the CD by trying the likely
locations : /dev/hd[abcd].
4. it then creates a 'tmpfs' file system and untars the
'XenDemoCD/root.tar.gz' file into the tmpfs. This contains hopefully
all the files that need to be mutable (this would be so much easier
if Linux supported 'stacked' or union file systems...)
5. Next, /linuxrc uses the pivot_root call to change the root file
system to the tmpfs, with the CD mounted as /usr.
6. It then invokes /sbin/init in the tmpfs and the boot proceeds
normally.
Building your own version of the XenDemoCD
==========================================
The 'live ISO' version of RedHat is based heavily on Peter Anvin's
SuperRescue CD version 2.1.2 and J. McDaniel's Plan-B:
http://www.kernel.org/pub/dist/superrescue/v2/
http://projectplanb.org/
Since Xen uses a "multiboot" image format, it was necessary to change
the bootloader from isolinux to Grub0.93 with Leonid Lisovskiy's
<lly@pisem.net> grub.0.93-iso9660.patch
The Xen Demo CD contains all of the build scripts that were used to
create it, so it is possible to 'unpack' the current iso, modifiy it,
then build a new iso. The procedure for doing so is as follows:
First, mount either the CD, or the iso image of the CD:
mount /dev/cdrom /mnt/cdrom
or:
mount -o loop xendemo-1.0.iso /mnt/cdrom
cd to the directory you want to 'unpack' the iso into then run the
unpack script:
cd /local/xendemocd
/mnt/cdrom/XenDemoCD/unpack-iso.sh
The result is a 'build' directory containing the file system tree
under the 'root' directory. e.g. /local/xendemocd/build/root
To add or remove rpms, its possible to use 'rpm' with the --root
option to set the path. For more complex changes, it easiest to boot a
machine using using the tree via NFS root. Before doing this, you'll
need to edit fstab to comment out the seperate mount of /usr.
One thing to watch out for: as part of the CD build process, the
contents of the 'rootpatch' tree gets copied over the existing 'root'
tree replacing various files. The intention of the rootpatch tree is
to contain the files that have been modified from the original RH
distribution (e.g. various /etc files). This was done to make it
easier to upgrade to newer RH versions in the future. The downside of
this is that if you edit an existing file in the root tree you should
check that you don't also need to propagate the change to the
rootpatch tree to avoid it being overwritten.
Once you've made the changes and want to build a new iso, here's the
procedure:
cd /local/xendemocd/build
echo '<put_your_name_here>' > Builder
./make.sh put_your_version_id_here >../buildlog 2>&1
This process can take 30 mins even on a fast machine, but you should
eventually end up with an iso image in the build directory.
Notes:
root - the root of the file system heirarchy as presented to the
running system
rootpatch - contains files that have been modified from the standard
RH, and copied over the root tree as part of the build
procedure.
irtree - the file system tree that will go into the initrd (initial
ram disk)
work - a working directory used in the build process
usr - this should really be in 'work' as its created as part of the
build process. It contains the 'immutable' files that will
be served from the CD rather than the tmpfs containing the
contents of root.tar.gz. Some files that are normally in /etc
or /var that are large and actually unlikely to need changing
have been moved into /usr/root and replaced with links.
Ian Pratt
9 Sep 2003
TODO
+34 -25
View File
@@ -1,43 +1,34 @@
Future plans and enhancements
=============================
For up-to-date details of features currently under implementation,
visit the Xen project roadmap at:
http://www.cl.cam.ac.uk/Research/SRG/netos/xen/roadmap.html
Known limitations and work in progress
======================================
The current Xen Virtual Firewall Router (VFR) implementation in the
snapshot tree is very rudimentary, and in particular, lacks the RSIP
IP port-space sharing across domains that provides a better
alternative to NAT. There's a complete new implementation under
development which also supports much better logging and auditing
support. For now, if you want NAT, see the xen_nat_enable scripts and
get domain0 to do it for you.
IO enhancements
---------------
There are also a number of memory management enhancements that didn't
make this release: We have plans for a "universal buffer cache" that
enables otherwise unused system memory to be used by domains in a
read-only fashion. We also have plans for inter-domain shared-memory
to enable high-performance bulk transport for cases where the usual
internal networking performance isn't good enough (e.g. communication
with a internal file server on another domain).
We have the equivalent of balloon driver functionality to control
domain's memory usage, enabling a domain to give back unused pages to
Xen. This needs properly documenting, and perhaps a way of domain0
signalling to a domain that it requires it to reduce its memory
footprint, rather than just the domain volunteering (see section on
the improved control interface).
read-only fashion.
Disk Scheduling
---------------
The current disk scheduler is rather simplistic (batch round robin),
and could be replaced by e.g. Cello if we have QoS isolation
problems. For most things it seems to work OK, but there's currently
no service differentiation or weighting.
Improved load-balancing
-----------------------
Currently, although Xen runs on SMP and SMT (hyperthreaded) machines,
the scheduling is far from smart -- domains are currently statically
assigned to a CPU when they are created (in a round robin fashion).
The scheduler needs to be modified such that before going idle a
logical CPU looks for work on other run queues (particularly on the
same physical CPU).
We'd like to see a user-space load-balancing daemon that can shift
domains between CPUs as their activity changes.
Multiprocessor Guest VMs
------------------------
Xen currently only supports uniprocessor guest OSes. We have designed
the Xen interface with MP guests in mind, and plan to build an MP
Linux guest in due course. Basically, an MP guest would consist of
@@ -48,3 +39,21 @@ page directory to a write-able page, we must ensure that no other CPU
still has the page in its TLB to ensure memory system integrity. One
other issue for supporting MP guests is that we'll need some sort of
CPU gang scheduler, which will require some research.
Cluster Management
------------------
There have been discussions regarding a unified cluster controller
for Xen deployments. This would leverage the existing features of
Xen to present a uniform control interface for managing a cluster
as a pool of resources, rather than a set of completely distinct
machines.
PAE Support on 32-bit x86
-------------------------
Xen can currently use up to 4GB of memory. It's possible for x86
machines to address more than that (64GB), but it requires using a
different page table format (3-level rather than 2-level) that we
currently don't support. Adding 3-level PAE support wouldn't be
difficult, but we'd also need to add support to all the guest
OSs. We do not plan to add this support ourselves but volunteers
are welcome!
docs/src/user.tex
+185 -28
View File
@@ -1,6 +1,7 @@
\documentclass[11pt,twoside,final,openright]{xenstyle}
\usepackage{a4,graphicx,setspace}
\setstretch{1.15}
%\input{style.tex}
\begin{document}
@@ -56,7 +57,7 @@ Contributions of material, suggestions and corrections are welcome.
}
Xen is a { \em paravirtualising } virtual machine monitor (VMM) or
``Hypervisor'' for the x86 processor architecture. Xen can securely
`Hypervisor' for the x86 processor architecture. Xen can securely
multiplex heterogeneous virtual machines on a single physical with
near-native performance. The virtual machine technology facilitates
enterprise-grade functionality, including:
@@ -119,9 +120,9 @@ Possible usage scenarios for Xen include:
drivers to achieve good hardware support
\end{description}
\section{Structure}
\section{Features}
\subsection{High level}
\subsection{High level structure}
A Xen system has multiple layers. The lowest layer is Xen itself ---
the most privileged piece of code in the system. On top of Xen run
@@ -137,7 +138,7 @@ their virtual devices. It also performs suspend, resume and
migration of other virtual machines. Where it is used, the X server
is also run in domain 0.
Within Domain 0, a process called ``Xend'' runs to manage the system.
Within Domain 0, a process called `Xend' runs to manage the system.
Xend is responsible for managing virtual machines and providing access
to their consoles. Commands are issued to Xend over an HTTP
interface, either from a command-line tool or from a web browser.
@@ -157,6 +158,31 @@ system kernels must explicitly support Xen in order to run in a
virtual machine, { \em user space applications and libraries
do not require modification }.
\subsection{Scalability}
We've successfully booted over 128 copies of Linux on the same machine
(a dual CPU hyperthreaded Xeon box) but we imagine that it would be
more normal to use some smaller number, perhaps 10-20.
A common question is `how many virtual machines can I run on hardware
xyz?'. The answer is very application dependent, but the rule of thumb
is that you should expect to be able to run the same workload under
multiple guest OSes that you could run under a single Linux instance,
with an additional overhead of a few MB per OS instance. This is
possible because of the low overhead of Xen's virtualisation strategy.
\subsection{Live Migration}
One key feature in this new release of Xen is `live migration'. This
enables virtual machines instances to be dynamically moved between
physical Xen machines, with typical {\em downtimes of just a few tens
of milliseconds}. The migration is almost imperceptible, even for
interactive users.
Live migration is very useful for admins that want to take a node down
for maintenance, or to load balance a large number of virtual machines
across a cluster.
\section{Hardware Support}
Xen currently runs on the x86 architecture, but could in principle be
@@ -168,7 +194,7 @@ at:\\
{\tt http://www.cl.cam.ac.uk/netos/papers/2003-xensosp.pdf}\\
Work to port Xen to x86\_64 and IA64 is currently underway.
Xen requires a ``P6'' or newer processor (e.g. Pentium Pro, Celeron,
Xen requires a `P6' or newer processor (e.g. Pentium Pro, Celeron,
Pentium II, Pentium III, Pentium IV, Xeon, AMD Athlon, AMD Duron).
Multiprocessor machines are supported, and we also have basic support
for HyperThreading (SMT), although this remains a topic for ongoing
@@ -195,12 +221,12 @@ other hardware by configuring your XenLinux kernel in the normal way
\section{History}
``Xen'' is a Virtual Machine Monitor (VMM) originally developed by the
`Xen' is a Virtual Machine Monitor (VMM) originally developed by the
Systems Research Group of the University of Cambridge Computer
Laboratory, as part of the UK-EPSRC funded XenoServers project.
The XenoServers project aims to provide a ``public infrastructure for
global distributed computing'', and Xen plays a key part in that,
The XenoServers project aims to provide a `public infrastructure for
global distributed computing', and Xen plays a key part in that,
allowing us to efficiently partition a single machine to enable
multiple independent clients to run their operating systems and
applications in an environment providing protection, resource
@@ -210,7 +236,7 @@ information along with pointers to papers and technical reports:
Xen has since grown into a project in its own right, enabling us to
investigate interesting research issues regarding the best techniques
for virtualizing resources such as the CPU, memory, disk and network.
for virtualising resources such as the CPU, memory, disk and network.
The project has been bolstered by support from Intel Research
Cambridge, and HP Labs, who are now working closely with us.
% We're also in receipt of support from Microsoft Research Cambridge to
@@ -330,7 +356,7 @@ The Xen source code repository is structured as follows:
\section{Build and install}
The Xen makefile includes a target ``world'' that will do the
The Xen makefile includes a target `world' that will do the
following:
\begin{itemize}
@@ -345,21 +371,21 @@ following:
Inspect the Makefile if you want to see what goes on during a build.
Building Xen and the tools is straightforward, but XenLinux is more
complicated. The makefile needs a `pristine' linux kernel tree which
complicated. The makefile needs a `pristine' Linux kernel tree which
it will then add the Xen architecture files to. You can tell the
makefile the location of the appropriate linux compressed tar file by
makefile the location of the appropriate Linux compressed tar file by
setting the LINUX\_SRC environment variable, e.g. \\
\verb!# LINUX_SRC=/tmp/linux-2.6.8.1.tar.bz2 make world! \\ or by
placing the tar file somewhere in the search path of {\tt
LINUX\_SRC\_PATH} which defaults to ``{\tt .:..}". If the makefile
LINUX\_SRC\_PATH} which defaults to `{\tt .:..}'. If the makefile
can't find a suitable kernel tar file it attempts to download it from
kernel.org (this won't work if you're behind a firewall).
After untaring the pristine kernel tree, the makefile uses the {\tt
mkbuildtree} script to add the Xen patches to the kernel. It then
builds two different XenLinux images, one with a ``-xen0'' extension
builds two different XenLinux images, one with a `-xen0' extension
which contains hardware device drivers and drivers for Xen's virtual
devices, and one with a ``-xenU'' extension that just contains the
devices, and one with a `-xenU' extension that just contains the
virtual ones.
The procedure is similar to build the Linux 2.4 port: \\
@@ -407,7 +433,7 @@ The difference between the two Linux kernels that are built is due to
the configuration file used for each. The "U" suffixed unprivileged
version doesn't contain any of the physical hardware device drivers
--- it is 30\% smaller and hence may be preferred for your
non-privileged domains. The ``0'' suffixed privileged version can be
non-privileged domains. The `0' suffixed privileged version can be
used to boot the system, as well as in driver domains and unprivileged
domains.
@@ -565,7 +591,7 @@ second to the location of \path{/usr} (if you are sharing it between
domains). [i.e. {\tt disk = ['phy:your\_hard\_drive\%d,sda1,w' \%
(base\_partition\_number + vmid), 'phy:your\_usr\_partition,sda6,r' ]}
\item[dhcp] Uncomment the dhcp variable, so that the domain will
receive its IP address from a DHCP server. [i.e. {\tt dhcp=''dhcp''}]
receive its IP address from a DHCP server. [i.e. {\tt dhcp='dhcp'}]
\end{description}
You may also want to edit the {\bf vif} variable in order to choose
@@ -631,8 +657,8 @@ configuration file (or a link to it) under \path{/etc/xen/auto/}.
A Sys-V style init script for RedHat and LSB-compliant systems is
provided and will be automatically copied to \path{/etc/init.d/}
during install. You can then enable it in the appriate way for your
distribution.
during install. You can then enable it in the appropriate way for
your distribution.
For instance, on RedHat:
@@ -723,13 +749,22 @@ or:
# xm console 5
\end{verbatim}
\chapter{Other kinds of storage}
\chapter{Domain filesystem storage}
It is possible to directly export any Linux block device to a virtual,
or to export filesystems / devices to virtual machines using standard
network protocals (e.g. NBD, iSCSI, NFS, etc). This chapter covers
network protocols (e.g. NBD, iSCSI, NFS, etc). This chapter covers
some of the possibilities.
\section{Warning: Block device sharing}
Block devices should only be shared between domains in a read-only
fashion otherwise the Linux kernels will obviously get very confused
as the file system structure may change underneath them (having the
same partition mounted rw twice is a sure fire way to cause
irreparable damage)! If you want read-write sharing, export the
directory to other domains via NFS from domain0.
\section{File-backed virtual block devices}
It is possible to use a file in Domain 0 as the primary storage for a
@@ -989,9 +1024,9 @@ domains and provides a user friendly domain creation wizard.
a complete system of real hardware devices.
\item[Hypervisor] An alternative term for { \bf VMM }, used
because it means ``beyond supervisor'',
because it means `beyond supervisor',
since it is responsible for managing multiple
``supervisor'' kernels.
`supervisor' kernels.
\item[Live migration] A technique for moving a running virtual
machine to another physical host, without
@@ -1049,8 +1084,8 @@ domains and provides a user friendly domain creation wizard.
\chapter{Advanced Network Configuration}
For simple systems with a single ethernet interface with a simple
configuration, the default installation should work ``out of the
box''. More complicated network setups, for instance with multiple
configuration, the default installation should work `out of the
box'. More complicated network setups, for instance with multiple
ethernet interfaces and / or existing bridging setups will require
some special configuration.
@@ -1073,7 +1108,7 @@ Xen virtual network when Xend starts and to do any corresponding
cleanup when Xend exits.
In the default configuration, this script creates the bridge
``xen-br0'' and moves eth0 onto that bridge, modifying the routing
`xen-br0' and moves eth0 onto that bridge, modifying the routing
accordingly.
In configurations where the bridge already exists, this script could
@@ -1254,13 +1289,32 @@ can be configured in either format of configuration file:
\section{Administration Domains}
Administration privileges allow a domain to use the ``dom0
operations'' (so called because they are usually available only to
Administration privileges allow a domain to use the `dom0
operations' (so called because they are usually available only to
domain 0). A privileged domain can build other domains, set scheduling
parameters, etc.
% Support for other administrative domains is not yet available...
\chapter{Debugging}
Xen has a set of debugging features that can be useful to try and
figure out what's going on. Hit 'h' on the serial line (if you
specified a baud rate on the Xen command line) or ScrollLock-h on the
keyboard to get a list of supported commands.
If you have a crash you'll likely get a crash dump containing an EIP
(PC) which, along with an 'objdump -d image', can be useful in
figuring out what's happened. Debug a Xenlinux image just as you
would any other Linux kernel.
We supply a handy debug terminal program which you can find in
/usr/local/src/xen-2.0.bk/tools/misc/miniterm/
This should be built and executed on another machine that is connected
via a null modem cable. Documentation is included.
Alternatively, if the Xen machine is connected to a serial-port server
then we supply a dumb TCP terminal client, {\tt xencons}.
\chapter{Xen build options}
For most users, the default build of Xen will be adequate. For some
@@ -1616,6 +1670,61 @@ template and the new image, and using {\tt cp -a} or {\tt tar} or by
simply copying the image file. Once this is done, modify the
image-specific settings (hostname, network settings, etc).
\chapter{Installing Xen / XenLinux on Redhat / Fedora}
When using Xen / Xenlinux on a standard Linux distribution there are
a couple of things to watch out for:
Note that, because domains>0 don't have any privileged access at all,
certain commands in the default boot sequence will fail e.g. attempts
to update the hwclock, change the console font, update the keytable
map, start apmd (power management), or gpm (mouse cursor). Either
ignore the errors (they should be harmless), or remove them from the
startup scripts. Deleting the following links are a good start:
S24pcmcia S09isdn S17keytable S26apmd S85gpm.
If you want to use a single root file system that works cleanly for
domain0 and domains>0, a useful trick is to use different 'init' run
levels. For example, on the Xen Demo CD we use run level 3 for domain
0, and run level 4 for domains>0. This enables different startup
scripts to be run in depending on the run level number passed on the
kernel command line.
If you're going to use NFS root files systems mounted either from an
external server or from domain0 there are a couple of other gotchas.
The default /etc/sysconfig/iptables rules block NFS, so part way
through the boot sequence things will suddenly go dead.
If you're planning on having a separate NFS /usr partition, the RH9
boot scripts don't make life easy - they attempt to mount NFS file
systems way to late in the boot process. The easiest way I found to do
this was to have a '/linuxrc' script run ahead of /sbin/init that
mounts /usr:
\begin{verbatim}
#!/bin/bash
/sbin/ipconfig lo 127.0.0.1
/sbin/portmap
/bin/mount /usr
exec /sbin/init "$@" <>/dev/console 2>&1
\end{verbatim}
The one slight complication with the above is that /sbib/portmap is
dynamically linked against /usr/lib/libwrap.so.0 Since this is in
/usr, it won't work. This can be solved by copying the file (and link)
below the /usr mount point, and just let the file be 'covered' when
the mount happens.
In some installations, where a shared read-only /usr is being used, it
may be desirable to move other large directories over into the
read-only /usr. For example, you might replace /bin /lib and /sbin
with links into /usr/root/bin /usr/root/lib and /usr/root/sbin
respectively. This creates other problems for running the /linuxrc
script, requiring bash, portmap, mount, ifconfig, and a handful of
other shared libraries to be copied below the mount point - little
statically linked C program would solve this problem.
\end{document}
@@ -1646,4 +1755,52 @@ image-specific settings (hostname, network settings, etc).
%% You can use these modules to write your own custom scripts or you can
%% customise the scripts supplied in the Xen distribution.
% Explain about AGP GART
%% If you're not intending to configure the new domain with an IP address
%% on your LAN, then you'll probably want to use NAT. The
%% 'xen_nat_enable' installs a few useful iptables rules into domain0 to
%% enable NAT. [NB: We plan to support RSIP in future]
%% Installing the file systems from the CD
%% =======================================
%% If you haven't got an existing Linux installation onto which you can
%% just drop down the Xen and Xenlinux images, then the file systems on
%% the CD provide a quick way of doing an install. However, you would be
%% better off in the long run doing a proper install of your preferred
%% distro and installing Xen onto that, rather than just doing the hack
%% described below:
%% Choose one or two partitions, depending on whether you want a separate
%% /usr or not. Make file systems on it/them e.g.:
%% mkfs -t ext3 /dev/hda3
%% [or mkfs -t ext2 /dev/hda3 && tune2fs -j /dev/hda3 if using an old
%% version of mkfs]
%% Next, mount the file system(s) e.g.:
%% mkdir /mnt/root && mount /dev/hda3 /mnt/root
%% [mkdir /mnt/usr && mount /dev/hda4 /mnt/usr]
%% To install the root file system, simply untar /usr/XenDemoCD/root.tar.gz:
%% cd /mnt/root && tar -zxpf /usr/XenDemoCD/root.tar.gz
%% You'll need to edit /mnt/root/etc/fstab to reflect your file system
%% configuration. Changing the password file (etc/shadow) is probably a
%% good idea too.
%% To install the usr file system, copy the file system from CD on /usr,
%% though leaving out the "XenDemoCD" and "boot" directories:
%% cd /usr && cp -a X11R6 etc java libexec root src bin dict kerberos local sbin tmp doc include lib man share /mnt/usr
%% If you intend to boot off these file systems (i.e. use them for
%% domain 0), then you probably want to copy the /usr/boot directory on
%% the cd over the top of the current symlink to /boot on your root
%% filesystem (after deleting the current symlink) i.e.:
%% cd /mnt/root ; rm boot ; cp -a /usr/boot .
tools/misc/Makefile
+1 -1
View File
@@ -17,7 +17,7 @@ HDRS = $(wildcard *.h)
SRCS = $(wildcard *.c)
OBJS = $(patsubst %.c,%.o,$(SRCS))
TARGETS = xen_cpuperf
TARGETS =
INSTALL_BIN = $(TARGETS) xencons
INSTALL_SBIN = netfix xm xend xensv
tools/misc/p4perf.h
-559
View File
@@ -1,559 +0,0 @@
/*
* For P6 use PERFCTR1 (0 used for APIC NMI watchdog). Must setup after
* APIC NMI watchdog setup. Note that if this previous setup doesn't happen
* we still must enable both counters.
*
* P4 Xeon with Hyperthreading has counters per physical package which can
* count events from either logical CPU. However, in many cases more than
* ECSR and CCCR/counter can be used to count the same event. For instr or
* uops retired, use either ESCR0/IQ_CCCR0 ESCR1/IQ_CCCR2.
*
* USE CONFIG_MPENTIUM4_HT for a P4 Xeon with hyperthreading.
*
* Note that the counters may be initialised on each logical processor
* which will cause each physical processor to be initialised twice. This
* should not cause a problem.
*/
#ifndef P4PERF_H
#define P4PERF_H
#ifdef __KERNEL__
#include <asm/msr.h>
#endif
/*****************************************************************************
* Performance counter configuration. *
*****************************************************************************/
#ifndef P6_EVNTSEL_OS
# define P6_EVNTSEL_OS (1 << 17)
# define P6_EVNTSEL_USR (1 << 16)
# define P6_EVNTSEL_E (1 << 18)
# define P6_EVNTSEL_EN (1 << 22)
#endif
#define P6_PERF_INST_RETIRED 0xc0
#define P6_PERF_UOPS_RETIRED 0xc2
#define P4_ESCR_USR (1 << 2)
#define P4_ESCR_OS (1 << 3)
#define P4_ESCR_T0_USR (1 << 2) /* First logical CPU */
#define P4_ESCR_T0_OS (1 << 3)
#define P4_ESCR_T1_USR (1 << 0) /* Second logical CPU */
#define P4_ESCR_T1_OS (1 << 1)
#define P4_ESCR_TE (1 << 4)
#define P4_ESCR_THREADS(t) (t)
#define P4_ESCR_TV(tag) (tag << 5)
#define P4_ESCR_EVNTSEL(e) (e << 25)
#define P4_ESCR_EVNTMASK(e) (e << 9)
#define P4_ESCR_EVNTSEL_FRONT_END 0x08
#define P4_ESCR_EVNTSEL_EXECUTION 0x0c
#define P4_ESCR_EVNTSEL_REPLAY 0x09
#define P4_ESCR_EVNTSEL_INSTR_RETIRED 0x02
#define P4_ESCR_EVNTSEL_UOPS_RETIRED 0x01
#define P4_ESCR_EVNTSEL_UOP_TYPE 0x02
#define P4_ESCR_EVNTSEL_RET_MBR_TYPE 0x05
//#define P4_ESCR_EVNTSEL_RET_MBR_TYPE 0x04
#define P4_ESCR_EVNTMASK_FE_NBOGUS 0x01
#define P4_ESCR_EVNTMASK_FE_BOGUS 0x02
#define P4_ESCR_EVNTMASK_EXEC_NBOGUS0 0x01
#define P4_ESCR_EVNTMASK_EXEC_NBOGUS1 0x02
#define P4_ESCR_EVNTMASK_EXEC_NBOGUS2 0x04
#define P4_ESCR_EVNTMASK_EXEC_NBOGUS3 0x08
#define P4_ESCR_EVNTMASK_EXEC_BOGUS0 0x10
#define P4_ESCR_EVNTMASK_EXEC_BOGUS1 0x20
#define P4_ESCR_EVNTMASK_EXEC_BOGUS2 0x40
#define P4_ESCR_EVNTMASK_EXEC_BOGUS3 0x80
#define P4_ESCR_EVNTMASK_REPLAY_NBOGUS 0x01
#define P4_ESCR_EVNTMASK_REPLAY_BOGUS 0x02
#define P4_ESCR_EVNTMASK_IRET_NB_NTAG 0x01
#define P4_ESCR_EVNTMASK_IRET_NB_TAG 0x02
#define P4_ESCR_EVNTMASK_IRET_B_NTAG 0x04
#define P4_ESCR_EVNTMASK_IRET_B_TAG 0x08
#define P4_ESCR_EVNTMASK_URET_NBOGUS 0x01
#define P4_ESCR_EVNTMASK_URET_BOGUS 0x02
#define P4_ESCR_EVNTMASK_UOP_LOADS 0x02
#define P4_ESCR_EVNTMASK_UOP_STORES 0x04
#define P4_ESCR_EVNTMASK_RMBRT_COND 0x02
#define P4_ESCR_EVNTMASK_RMBRT_CALL 0x04
#define P4_ESCR_EVNTMASK_RMBRT_RETURN 0x08
#define P4_ESCR_EVNTMASK_RMBRT_INDIR 0x10
#define P4_ESCR_EVNTMASK_RBRT_COND 0x02
#define P4_ESCR_EVNTMASK_RBRT_CALL 0x04
#define P4_ESCR_EVNTMASK_RBRT_RETURN 0x08
#define P4_ESCR_EVNTMASK_RBRT_INDIR 0x10
//#define P4_ESCR_EVNTMASK_INSTR_RETIRED 0x01 /* Non bogus, not tagged */
//#define P4_ESCR_EVNTMASK_UOPS_RETIRED 0x01 /* Non bogus */
#define P4_CCCR_OVF (1 << 31)
#define P4_CCCR_CASCADE (1 << 30)
#define P4_CCCR_FORCE_OVF (1 << 25)
#define P4_CCCR_EDGE (1 << 24)
#define P4_CCCR_COMPLEMENT (1 << 19)
#define P4_CCCR_COMPARE (1 << 18)
#define P4_CCCR_THRESHOLD(t) (t << 20)
#define P4_CCCR_ENABLE (1 << 12)
#define P4_CCCR_ESCR(escr) (escr << 13)
#define P4_CCCR_ACTIVE_THREAD(t) (t << 16) /* Set to 11 */
#define P4_CCCR_OVF_PMI_T0 (1 << 26)
#define P4_CCCR_OVF_PMI_T1 (1 << 27)
#define P4_CCCR_RESERVED (3 << 16)
#define P4_CCCR_OVF_PMI (1 << 26)
// BPU
#define MSR_P4_BPU_COUNTER0 0x300
#define MSR_P4_BPU_COUNTER1 0x301
#define MSR_P4_BPU_CCCR0 0x360
#define MSR_P4_BPU_CCCR1 0x361
#define MSR_P4_BPU_COUNTER2 0x302
#define MSR_P4_BPU_COUNTER3 0x303
#define MSR_P4_BPU_CCCR2 0x362
#define MSR_P4_BPU_CCCR3 0x363
#define MSR_P4_BSU_ESCR0 0x3a0
#define MSR_P4_FSB_ESCR0 0x3a2
#define MSR_P4_MOB_ESCR0 0x3aa
#define MSR_P4_PMH_ESCR0 0x3ac
#define MSR_P4_BPU_ESCR0 0x3b2
#define MSR_P4_IS_ESCR0 0x3b4
#define MSR_P4_ITLB_ESCR0 0x3b6
#define MSR_P4_IX_ESCR0 0x3c8
#define P4_BSU_ESCR0_NUMBER 7
#define P4_FSB_ESCR0_NUMBER 6
#define P4_MOB_ESCR0_NUMBER 2
#define P4_PMH_ESCR0_NUMBER 4
#define P4_BPU_ESCR0_NUMBER 0
#define P4_IS_ESCR0_NUMBER 1
#define P4_ITLB_ESCR0_NUMBER 3
#define P4_IX_ESCR0_NUMBER 5
#define MSR_P4_BSU_ESCR1 0x3a1
#define MSR_P4_FSB_ESCR1 0x3a3
#define MSR_P4_MOB_ESCR1 0x3ab
#define MSR_P4_PMH_ESCR1 0x3ad
#define MSR_P4_BPU_ESCR1 0x3b3
#define MSR_P4_IS_ESCR1 0x3b5
#define MSR_P4_ITLB_ESCR1 0x3b7
#define MSR_P4_IX_ESCR1 0x3c9
#define P4_BSU_ESCR1_NUMBER 7
#define P4_FSB_ESCR1_NUMBER 6
#define P4_MOB_ESCR1_NUMBER 2
#define P4_PMH_ESCR1_NUMBER 4
#define P4_BPU_ESCR1_NUMBER 0
#define P4_IS_ESCR1_NUMBER 1
#define P4_ITLB_ESCR1_NUMBER 3
#define P4_IX_ESCR1_NUMBER 5
// MS
#define MSR_P4_MS_COUNTER0 0x304
#define MSR_P4_MS_COUNTER1 0x305
#define MSR_P4_MS_CCCR0 0x364
#define MSR_P4_MS_CCCR1 0x365
#define MSR_P4_MS_COUNTER2 0x306
#define MSR_P4_MS_COUNTER3 0x307
#define MSR_P4_MS_CCCR2 0x366
#define MSR_P4_MS_CCCR3 0x367
#define MSR_P4_MS_ESCR0 0x3c0
#define MSR_P4_TBPU_ESCR0 0x3c2
#define MSR_P4_TC_ESCR0 0x3c4
#define P4_MS_ESCR0_NUMBER 0
#define P4_TBPU_ESCR0_NUMBER 2
#define P4_TC_ESCR0_NUMBER 1
#define MSR_P4_MS_ESCR1 0x3c1
#define MSR_P4_TBPU_ESCR1 0x3c3
#define MSR_P4_TC_ESCR1 0x3c5
#define P4_MS_ESCR1_NUMBER 0
#define P4_TBPU_ESCR1_NUMBER 2
#define P4_TC_ESCR1_NUMBER 1
// FLAME
#define MSR_P4_FLAME_COUNTER0 0x308
#define MSR_P4_FLAME_COUNTER1 0x309
#define MSR_P4_FLAME_CCCR0 0x368
#define MSR_P4_FLAME_CCCR1 0x369
#define MSR_P4_FLAME_COUNTER2 0x30a
#define MSR_P4_FLAME_COUNTER3 0x30b
#define MSR_P4_FLAME_CCCR2 0x36a
#define MSR_P4_FLAME_CCCR3 0x36b
#define MSR_P4_FIRM_ESCR0 0x3a4
#define MSR_P4_FLAME_ESCR0 0x3a6
#define MSR_P4_DAC_ESCR0 0x3a8
#define MSR_P4_SAAT_ESCR0 0x3ae
#define MSR_P4_U2L_ESCR0 0x3b0
#define P4_FIRM_ESCR0_NUMBER 1
#define P4_FLAME_ESCR0_NUMBER 0
#define P4_DAC_ESCR0_NUMBER 5
#define P4_SAAT_ESCR0_NUMBER 2
#define P4_U2L_ESCR0_NUMBER 3
#define MSR_P4_FIRM_ESCR1 0x3a5
#define MSR_P4_FLAME_ESCR1 0x3a7
#define MSR_P4_DAC_ESCR1 0x3a9
#define MSR_P4_SAAT_ESCR1 0x3af
#define MSR_P4_U2L_ESCR1 0x3b1
#define P4_FIRM_ESCR1_NUMBER 1
#define P4_FLAME_ESCR1_NUMBER 0
#define P4_DAC_ESCR1_NUMBER 5
#define P4_SAAT_ESCR1_NUMBER 2
#define P4_U2L_ESCR1_NUMBER 3
// IQ
#define MSR_P4_IQ_COUNTER0 0x30c
#define MSR_P4_IQ_COUNTER1 0x30d
#define MSR_P4_IQ_CCCR0 0x36c
#define MSR_P4_IQ_CCCR1 0x36d
#define MSR_P4_IQ_COUNTER2 0x30e
#define MSR_P4_IQ_COUNTER3 0x30f
#define MSR_P4_IQ_CCCR2 0x36e
#define MSR_P4_IQ_CCCR3 0x36f
#define MSR_P4_IQ_COUNTER4 0x310
#define MSR_P4_IQ_COUNTER5 0x311
#define MSR_P4_IQ_CCCR4 0x370
#define MSR_P4_IQ_CCCR5 0x371
#define MSR_P4_CRU_ESCR0 0x3b8
#define MSR_P4_CRU_ESCR2 0x3cc
#define MSR_P4_CRU_ESCR4 0x3e0
#define MSR_P4_IQ_ESCR0 0x3ba
#define MSR_P4_RAT_ESCR0 0x3bc
#define MSR_P4_SSU_ESCR0 0x3be
#define MSR_P4_ALF_ESCR0 0x3ca
#define P4_CRU_ESCR0_NUMBER 4
#define P4_CRU_ESCR2_NUMBER 5
#define P4_CRU_ESCR4_NUMBER 6
#define P4_IQ_ESCR0_NUMBER 0
#define P4_RAT_ESCR0_NUMBER 2
#define P4_SSU_ESCR0_NUMBER 3
#define P4_ALF_ESCR0_NUMBER 1
#define MSR_P4_CRU_ESCR1 0x3b9
#define MSR_P4_CRU_ESCR3 0x3cd
#define MSR_P4_CRU_ESCR5 0x3e1
#define MSR_P4_IQ_ESCR1 0x3bb
#define MSR_P4_RAT_ESCR1 0x3bd
#define MSR_P4_ALF_ESCR1 0x3cb
#define P4_CRU_ESCR1_NUMBER 4
#define P4_CRU_ESCR3_NUMBER 5
#define P4_CRU_ESCR5_NUMBER 6
#define P4_IQ_ESCR1_NUMBER 0
#define P4_RAT_ESCR1_NUMBER 2
#define P4_ALF_ESCR1_NUMBER 1
#define P4_BPU_COUNTER0_NUMBER 0
#define P4_BPU_COUNTER1_NUMBER 1
#define P4_BPU_COUNTER2_NUMBER 2
#define P4_BPU_COUNTER3_NUMBER 3
#define P4_MS_COUNTER0_NUMBER 4
#define P4_MS_COUNTER1_NUMBER 5
#define P4_MS_COUNTER2_NUMBER 6
#define P4_MS_COUNTER3_NUMBER 7
#define P4_FLAME_COUNTER0_NUMBER 8
#define P4_FLAME_COUNTER1_NUMBER 9
#define P4_FLAME_COUNTER2_NUMBER 10
#define P4_FLAME_COUNTER3_NUMBER 11
#define P4_IQ_COUNTER0_NUMBER 12
#define P4_IQ_COUNTER1_NUMBER 13
#define P4_IQ_COUNTER2_NUMBER 14
#define P4_IQ_COUNTER3_NUMBER 15
#define P4_IQ_COUNTER4_NUMBER 16
#define P4_IQ_COUNTER5_NUMBER 17
/* PEBS
*/
#define MSR_P4_PEBS_ENABLE 0x3F1
#define MSR_P4_PEBS_MATRIX_VERT 0x3F2
#define P4_PEBS_ENABLE_MY_THR (1 << 25)
#define P4_PEBS_ENABLE_OTH_THR (1 << 26)
#define P4_PEBS_ENABLE (1 << 24)
#define P4_PEBS_BIT0 (1 << 0)
#define P4_PEBS_BIT1 (1 << 1)
#define P4_PEBS_BIT2 (1 << 2)
#define P4_PEBS_MATRIX_VERT_BIT0 (1 << 0)
#define P4_PEBS_MATRIX_VERT_BIT1 (1 << 1)
#define P4_PEBS_MATRIX_VERT_BIT2 (1 << 2)
/* Replay tagging.
*/
#define P4_REPLAY_TAGGING_PEBS_L1LMR P4_PEBS_BIT0
#define P4_REPLAY_TAGGING_PEBS_L2LMR P4_PEBS_BIT1
#define P4_REPLAY_TAGGING_PEBS_DTLMR P4_PEBS_BIT2
#define P4_REPLAY_TAGGING_PEBS_DTSMR P4_PEBS_BIT2
#define P4_REPLAY_TAGGING_PEBS_DTAMR P4_PEBS_BIT2
#define P4_REPLAY_TAGGING_VERT_L1LMR P4_PEBS_MATRIX_VERT_BIT0
#define P4_REPLAY_TAGGING_VERT_L2LMR P4_PEBS_MATRIX_VERT_BIT0
#define P4_REPLAY_TAGGING_VERT_DTLMR P4_PEBS_MATRIX_VERT_BIT0
#define P4_REPLAY_TAGGING_VERT_DTSMR P4_PEBS_MATRIX_VERT_BIT1
#define P4_REPLAY_TAGGING_VERT_DTAMR P4_PEBS_MATRIX_VERT_BIT0 | P4_PEBS_MATRIX_VERT_BIT1
/*****************************************************************************
* *
*****************************************************************************/
// x87_FP_uop
#define EVENT_SEL_x87_FP_uop 0x04
#define EVENT_MASK_x87_FP_uop_ALL (1 << 15)
// execution event (at retirement)
#define EVENT_SEL_execution_event 0x0C
// scalar_SP_uop
#define EVENT_SEL_scalar_SP_uop 0x0a
#define EVENT_MASK_scalar_SP_uop_ALL (1 << 15)
// scalar_DP_uop
#define EVENT_SEL_scalar_DP_uop 0x0e
#define EVENT_MASK_scalar_DP_uop_ALL (1 << 15)
// Instruction retired
#define EVENT_SEL_instr_retired 0x02
#define EVENT_MASK_instr_retired_ALL 0x0f
// uOps retired
#define EVENT_SEL_uops_retired 0x01
#define EVENT_MASK_uops_retired_ALL 0x03
// L1 misses retired
#define EVENT_SEL_replay_event 0x09
#define EVENT_MASK_replay_event_ALL 0x03
// Trace cache
#define EVENT_SEL_BPU_fetch_request 0x03
#define EVENT_MASK_BPU_fetch_request_TCMISS 0x01
// Bus activity
#define EVENT_SEL_FSB_data_activity 0x17
#define EVENT_MASK_FSB_data_activity_DRDY_DRV 0x01
#define EVENT_MASK_FSB_data_activity_DRDY_OWN 0x02
#define EVENT_MASK_FSB_data_activity_DRDY_OOTHER 0x04
#define EVENT_MASK_FSB_data_activity_DBSY_DRV 0x08
#define EVENT_MASK_FSB_data_activity_DBSY_OWN 0x10
#define EVENT_MASK_FSB_data_activity_DBSY_OOTHER 0x20
// Cache L2
#define EVENT_SEL_BSQ_cache_reference 0x0c
#define EVENT_MASK_BSQ_cache_reference_RD_L2_HITS 0x001
#define EVENT_MASK_BSQ_cache_reference_RD_L2_HITE 0x002
#define EVENT_MASK_BSQ_cache_reference_RD_L2_HITM 0x004
#define EVENT_MASK_BSQ_cache_reference_RD_L3_HITS 0x008
#define EVENT_MASK_BSQ_cache_reference_RD_L3_HITE 0x010
#define EVENT_MASK_BSQ_cache_reference_RD_L3_HITM 0x020
#define EVENT_MASK_BSQ_cache_reference_RD_L2_MISS 0x100
#define EVENT_MASK_BSQ_cache_reference_RD_L3_MISS 0x200
#define EVENT_MASK_BSQ_cache_reference_WR_L2_MISS 0x400
/*****************************************************************************
* *
*****************************************************************************/
/* The following turn configuration macros into 1/0 to allow code to be
* selected using if(MPENTIUM4_HT) rather then #ifdef (to avoid stale code).
* We rely on the compiler to optimise out unreachable code,
*/
#ifdef CONFIG_MPENTIUM4_HT
# define MPENTIUM4_HT 1
#else
# define MPENTIUM4_HT 0
#endif
#ifdef CONFIG_MPENTIUMIII
# define MPENTIUMIII 1
#else
# define MPENTIUMIII 0
#endif
#ifdef CONFIG_MPENTIUM4
# define MPENTIUM4 1
#else
# define MPENTIUM4 0
#endif
/*****************************************************************************
* MSR access macros *
*****************************************************************************/
/* rpcc: get full 64-bit Pentium TSC value
*/
static __inline__ unsigned long long int rpcc(void)
{
unsigned int __h, __l;
__asm__ __volatile__ ("rdtsc" :"=a" (__l), "=d" (__h));
return (((unsigned long long)__h) << 32) + __l;
}
/*****************************************************************************
* Functions. *
*****************************************************************************/
#ifdef __KERNEL__
static inline void smt_sched_setup(void)
{
if (MPENTIUMIII) {
unsigned int evntsel, x;
/* Make sure counters enabled. */
rdmsr(MSR_P6_EVNTSEL0, evntsel, x);
evntsel |= P6_EVNTSEL_EN;
wrmsr(MSR_P6_EVNTSEL0, evntsel, 0);
evntsel =
P6_PERF_INST_RETIRED |
P6_EVNTSEL_OS |
P6_EVNTSEL_USR |
P6_EVNTSEL_E;
wrmsr(MSR_P6_EVNTSEL1, evntsel, 0);
}
if(MPENTIUM4) {
unsigned int x;
/* Program the ESCR */
x = P4_ESCR_USR |
P4_ESCR_OS |
P4_ESCR_EVNTSEL(P4_ESCR_EVNTSEL_INSTR_RETIRED) |
P4_ESCR_EVNTMASK(P4_ESCR_EVNTMASK_IRET_NB_NTAG);
wrmsr(MSR_P4_CRU_ESCR0, x, 0);
/* Program the CCCR */
if (MPENTIUM4_HT) {
x = P4_CCCR_ENABLE |
P4_CCCR_ESCR(P4_CRU_ESCR0_NUMBER) |
P4_CCCR_ACTIVE_THREAD(3);
}
else {
x = P4_CCCR_ENABLE |
P4_CCCR_ESCR(P4_CRU_ESCR0_NUMBER) |
P4_CCCR_RESERVED;
}
wrmsr(MSR_P4_IQ_CCCR0, x, 0);
if (MPENTIUM4_HT) {
/* Program the second ESCR */
x = P4_ESCR_T1_USR |
P4_ESCR_T1_OS |
P4_ESCR_EVNTSEL(P4_ESCR_EVNTSEL_INSTR_RETIRED) |
P4_ESCR_EVNTMASK(P4_ESCR_EVNTMASK_IRET_NB_NTAG);
wrmsr(MSR_P4_CRU_ESCR1, x, 0);
/* Program the second CCCR */
x = P4_CCCR_ENABLE |
P4_CCCR_ESCR(P4_CRU_ESCR1_NUMBER) |
P4_CCCR_ACTIVE_THREAD(3);
wrmsr(MSR_P4_IQ_CCCR2, x, 0);
}
}
if (!MPENTIUMIII && !MPENTIUM4) {
printk("WARNING: Not setting up IPC performance counters.\n");
} else {
printk("Setting up IPC performance counters.\n");
}
}
#ifdef CONFIG_MPENTIUMIII
# define MY_MSR_COUNTER MSR_P6_PERFCTR1
#endif
#ifdef CONFIG_MPENTIUM4
# define MY_MSR_COUNTER MSR_P4_IQ_COUNTER0
#endif
#ifndef MY_MSR_COUNTER
# define MY_MSR_COUNTER 0 /* Never used but ensures compilation */
#endif
#define MY_MSR_COUNTER0 MSR_P4_IQ_COUNTER0
#define MY_MSR_COUNTER1 MSR_P4_IQ_COUNTER2
# define smt_sched_start_sample(task) \
{ \
unsigned int l, h; \
\
if (MPENTIUM4_HT) { \
unsigned int msr = \
(task->processor & 1)?MY_MSR_COUNTER1:MY_MSR_COUNTER0; \
rdmsr(msr, l, h); \
} \
else { \
rdmsr(MY_MSR_COUNTER, l, h); \
} \
task->ipc_sample_start_count_lo = l; \
task->ipc_sample_start_count_hi = h; \
rdtsc(l, h); \
task->ipc_sample_start_cycle_lo = l; \
task->ipc_sample_start_cycle_hi = h; \
}
# define smt_sched_stop_sample(task) \
{ \
if (task->ipc_sample_start_cycle_hi != 0) \
{ \
unsigned int cl, ch, tl, th; \
unsigned int c, t; \
\
if (MPENTIUM4_HT) { \
unsigned int msr = \
(task->processor & 1)?MY_MSR_COUNTER1:MY_MSR_COUNTER0; \
rdmsr(msr, cl, ch); \
} \
else { \
rdmsr(MY_MSR_COUNTER, cl, ch); \
} \
\
rdtsc(tl, th); \
\
c = cl - task->ipc_sample_start_count_lo; \
t = tl - task->ipc_sample_start_cycle_lo; \
task->ipc_average = IPC_AVERAGE(task->ipc_average, \
((double)c)/((double)t)); \
task->ipc_sample_start_cycle_hi = 0; \
\
} \
else \
task->ipc_average = 0.0; \
\
}
// task->ipc_sample_latest =
// (unsigned int)(1000.0*((double)c)/((double)t));
#endif /* __KERNEL__ */
#endif /* P4PERF_H */
/* End of $RCSfile$ */
tools/misc/setdomainmaxmem
-34
View File
@@ -1,34 +0,0 @@
#!/usr/bin/env perl
use strict;
require "sys/ioctl.ph";
sub SIZEOF_HYPERCALL () { 24; }
sub STRUCT_PRIVCMD_HYPERCALL () {"L P";}
sub IOCTL_PRIVCMD_HYPERCALL ()
{ &_IOC( &_IOC_NONE, ord('P'), 0, SIZEOF_HYPERCALL );}
sub __HYPERVISOR_dom0_op () {7;}
sub DOM0_INTERFACE_VERSION () {0xaaaa0010;}
sub DOM0_SETDOMAINMAXMEM () {28;}
sub STRUCT_DOM0_OP_PREFIX () {"L L";}
sub STRUCT_SETDOMAINMAXMEM () {STRUCT_DOM0_OP_PREFIX."L x4 L";}
sub XEN_PRIVCMD () {"/proc/xen/privcmd";}
sub setdomainmaxmem($$) {
my ($domain,$bytes) = @_;
my $msg = pack(STRUCT_SETDOMAINMAXMEM,DOM0_SETDOMAINMAXMEM,
DOM0_INTERFACE_VERSION, $domain, $bytes);
my $cmd = pack(STRUCT_PRIVCMD_HYPERCALL,__HYPERVISOR_dom0_op,$msg);
open(XEN,XEN_PRIVCMD) or die "$!\n";
ioctl(XEN, IOCTL_PRIVCMD_HYPERCALL, $cmd) or die "ioctl: $!";
close XEN;
}
my ($bytes,$suffix) = $ARGV[1] =~ m/(^\d+)([mMkKgG])/;
$bytes<<=10 if $suffix =~ m/[kK]/;
$bytes<<=20 if $suffix =~ m/[mM]/;
$bytes<<=30 if $suffix =~ m/[gG]/;
printf "set domain $ARGV[0] to $bytes\n";
setdomainmaxmem($ARGV[0],$bytes);
tools/misc/xen_cpuperf.c
-271
View File
@@ -1,271 +0,0 @@
/*
* User mode program to prod MSR values through /proc/perfcntr
*/
#include <sys/types.h>
#include <sched.h>
#include <error.h>
#include <stdio.h>
#include <unistd.h>
#include <stdlib.h>
#include <string.h>
#include "p4perf.h"
#include "xc_private.h"
void dom0_wrmsr( int privfd,
int cpu_mask,
int msr,
unsigned int low,
unsigned int high )
{
dom0_op_t op;
op.cmd = DOM0_MSR;
op.u.msr.write = 1;
op.u.msr.msr = msr;
op.u.msr.cpu_mask = cpu_mask;
op.u.msr.in1 = low;
op.u.msr.in2 = high;
do_dom0_op(privfd, &op);
}
unsigned long long dom0_rdmsr( int privfd,
int cpu_mask,
int msr )
{
dom0_op_t op;
op.cmd = DOM0_MSR;
op.u.msr.write = 0;
op.u.msr.msr = msr;
op.u.msr.cpu_mask = cpu_mask;
do_dom0_op(privfd, &op);
return (((unsigned long long)op.u.msr.out2)<<32) | op.u.msr.out1 ;
}
struct macros {
char *name;
unsigned long msr_addr;
int number;
};
struct macros msr[] = {
{"BPU_COUNTER0", 0x300, 0},
{"BPU_COUNTER1", 0x301, 1},
{"BPU_COUNTER2", 0x302, 2},
{"BPU_COUNTER3", 0x303, 3},
{"MS_COUNTER0", 0x304, 4},
{"MS_COUNTER1", 0x305, 5},
{"MS_COUNTER2", 0x306, 6},
{"MS_COUNTER3", 0x307, 7},
{"FLAME_COUNTER0", 0x308, 8},
{"FLAME_COUNTER1", 0x309, 9},
{"FLAME_COUNTER2", 0x30a, 10},
{"FLAME_COUNTER3", 0x30b, 11},
{"IQ_COUNTER0", 0x30c, 12},
{"IQ_COUNTER1", 0x30d, 13},
{"IQ_COUNTER2", 0x30e, 14},
{"IQ_COUNTER3", 0x30f, 15},
{"IQ_COUNTER4", 0x310, 16},
{"IQ_COUNTER5", 0x311, 17},
{"BPU_CCCR0", 0x360, 0},
{"BPU_CCCR1", 0x361, 1},
{"BPU_CCCR2", 0x362, 2},
{"BPU_CCCR3", 0x363, 3},
{"MS_CCCR0", 0x364, 4},
{"MS_CCCR1", 0x365, 5},
{"MS_CCCR2", 0x366, 6},
{"MS_CCCR3", 0x367, 7},
{"FLAME_CCCR0", 0x368, 8},
{"FLAME_CCCR1", 0x369, 9},
{"FLAME_CCCR2", 0x36a, 10},
{"FLAME_CCCR3", 0x36b, 11},
{"IQ_CCCR0", 0x36c, 12},
{"IQ_CCCR1", 0x36d, 13},
{"IQ_CCCR2", 0x36e, 14},
{"IQ_CCCR3", 0x36f, 15},
{"IQ_CCCR4", 0x370, 16},
{"IQ_CCCR5", 0x371, 17},
{"BSU_ESCR0", 0x3a0, 7},
{"BSU_ESCR1", 0x3a1, 7},
{"FSB_ESCR0", 0x3a2, 6},
{"FSB_ESCR1", 0x3a3, 6},
{"MOB_ESCR0", 0x3aa, 2},
{"MOB_ESCR1", 0x3ab, 2},
{"PMH_ESCR0", 0x3ac, 4},
{"PMH_ESCR1", 0x3ad, 4},
{"BPU_ESCR0", 0x3b2, 0},
{"BPU_ESCR1", 0x3b3, 0},
{"IS_ESCR0", 0x3b4, 1},
{"IS_ESCR1", 0x3b5, 1},
{"ITLB_ESCR0", 0x3b6, 3},
{"ITLB_ESCR1", 0x3b7, 3},
{"IX_ESCR0", 0x3c8, 5},
{"IX_ESCR1", 0x3c9, 5},
{"MS_ESCR0", 0x3c0, 0},
{"MS_ESCR1", 0x3c1, 0},
{"TBPU_ESCR0", 0x3c2, 2},
{"TBPU_ESCR1", 0x3c3, 2},
{"TC_ESCR0", 0x3c4, 1},
{"TC_ESCR1", 0x3c5, 1},
{"FIRM_ESCR0", 0x3a4, 1},
{"FIRM_ESCR1", 0x3a5, 1},
{"FLAME_ESCR0", 0x3a6, 0},
{"FLAME_ESCR1", 0x3a7, 0},
{"DAC_ESCR0", 0x3a8, 5},
{"DAC_ESCR1", 0x3a9, 5},
{"SAAT_ESCR0", 0x3ae, 2},
{"SAAT_ESCR1", 0x3af, 2},
{"U2L_ESCR0", 0x3b0, 3},
{"U2L_ESCR1", 0x3b1, 3},
{"CRU_ESCR0", 0x3b8, 4},
{"CRU_ESCR1", 0x3b9, 4},
{"CRU_ESCR2", 0x3cc, 5},
{"CRU_ESCR3", 0x3cd, 5},
{"CRU_ESCR4", 0x3e0, 6},
{"CRU_ESCR5", 0x3e1, 6},
{"IQ_ESCR0", 0x3ba, 0},
{"IQ_ESCR1", 0x3bb, 0},
{"RAT_ESCR0", 0x3bc, 2},
{"RAT_ESCR1", 0x3bd, 2},
{"SSU_ESCR0", 0x3be, 3},
{"SSU_ESCR1", 0x3bf, 3},
{"ALF_ESCR0", 0x3ca, 1},
{"ALF_ESCR1", 0x3cb, 1},
{"PEBS_ENABLE", 0x3f1, 0},
{"PEBS_MATRIX_VERT", 0x3f2, 0},
{NULL, 0, 0}
};
struct macros *lookup_macro(char *str)
{
struct macros *m;
m = msr;
while (m->name) {
if (strcmp(m->name, str) == 0)
return m;
m++;
}
return NULL;
}
int main(int argc, char **argv)
{
int c, t = 0xc, es = 0, em = 0, tv = 0, te = 0;
unsigned int cpu_mask = 1;
struct macros *escr = NULL, *cccr = NULL;
unsigned long escr_val, cccr_val;
int debug = 0;
unsigned long pebs = 0, pebs_vert = 0;
int pebs_x = 0, pebs_vert_x = 0;
int read = 0, privfd;
while ((c = getopt(argc, argv, "dc:t:e:m:T:E:C:P:V:r")) != -1) {
switch((char)c) {
case 'P':
pebs |= 1 << atoi(optarg);
pebs_x = 1;
break;
case 'V':
pebs_vert |= 1 << atoi(optarg);
pebs_vert_x = 1;
break;
case 'd':
debug = 1;
break;
case 'c':
{
int cpu = atoi(optarg);
cpu_mask = (cpu == -1)?(~0):(1<<cpu);
break;
}
case 't': // ESCR thread bits
t = atoi(optarg);
break;
case 'e': // eventsel
es = atoi(optarg);
break;
case 'm': // eventmask
em = atoi(optarg);
break;
case 'T': // tag value
tv = atoi(optarg);
te = 1;
break;
case 'E':
escr = lookup_macro(optarg);
if (!escr) {
fprintf(stderr, "Macro '%s' not found.\n", optarg);
exit(1);
}
break;
case 'C':
cccr = lookup_macro(optarg);
if (!cccr) {
fprintf(stderr, "Macro '%s' not found.\n", optarg);
exit(1);
}
break;
case 'r':
read = 1;
break;
}
}
if ( (privfd = open("/proc/xen/privcmd", O_RDWR)) == -1 )
{
fprintf(stderr, "Could not open privileged Xen control interface.\n");
exit(1);
}
if (read) {
while((cpu_mask&1)) {
int i;
for (i=0x300;i<0x312;i++)
{
printf("%010llx ",dom0_rdmsr( privfd, cpu_mask, i ) );
}
printf("\n");
cpu_mask>>=1;
}
exit(1);
}
if (!escr) {
fprintf(stderr, "Need an ESCR.\n");
exit(1);
}
if (!cccr) {
fprintf(stderr, "Need a counter number.\n");
exit(1);
}
escr_val = P4_ESCR_THREADS(t) | P4_ESCR_EVNTSEL(es) |
P4_ESCR_EVNTMASK(em) | P4_ESCR_TV(tv) | ((te)?P4_ESCR_TE:0);
cccr_val = P4_CCCR_ENABLE | P4_CCCR_ESCR(escr->number) |
P4_CCCR_ACTIVE_THREAD(3)/*reserved*/;
if (debug) {
fprintf(stderr, "ESCR 0x%lx <= 0x%08lx\n", escr->msr_addr, escr_val);
fprintf(stderr, "CCCR 0x%lx <= 0x%08lx (%u)\n",
cccr->msr_addr, cccr_val, cccr->number);
if (pebs_x)
fprintf(stderr, "PEBS 0x%x <= 0x%08lx\n",
MSR_P4_PEBS_ENABLE, pebs);
if (pebs_vert_x)
fprintf(stderr, "PMV 0x%x <= 0x%08lx\n",
MSR_P4_PEBS_MATRIX_VERT, pebs_vert);
}
dom0_wrmsr( privfd, cpu_mask, escr->msr_addr, escr_val, 0 );
dom0_wrmsr( privfd, cpu_mask, cccr->msr_addr, cccr_val, 0 );
if (pebs_x)
dom0_wrmsr( privfd, cpu_mask, MSR_P4_PEBS_ENABLE, pebs, 0 );
if (pebs_vert_x)
dom0_wrmsr( privfd, cpu_mask, MSR_P4_PEBS_MATRIX_VERT, pebs_vert, 0 );
return 0;
}
tools/misc/xensymoops.py → tools/misc/xensymoops
View File
File renamed without changes.
Reference in new issue
xen-project/xen
Block a user
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.

The note is not visible to the blocked user.