mirror of
https://github.com/xen-project/xen.git
synced 2026-10-28 02:01:24 +01:00
bitkeeper revision 1.1159.64.1 (4130aba0phC6BxiRx2cnmE5EUnUgTQ)
Update version numbers. Need some update of the actual instructions, particularly in README.CD.
This commit is contained in:
1 parent
bc76bb665d
commit
1d9f9b80cd
11 files changed
+91
-88
No files matched your search
@@ -28,6 +28,7 @@ laudney@eclipse.(none)
|
||||
lynx@idefix.cl.cam.ac.uk
|
||||
maw48@labyrinth.cl.cam.ac.uk
|
||||
mjw@wray-m-3.hpl.hp.com
|
||||
mwilli2@equilibrium.research
|
||||
mwilli2@equilibrium.research.intel-research.net
|
||||
rac61@labyrinth.cl.cam.ac.uk
|
||||
rgr22@boulderdash.cl.cam.ac.uk
|
||||
|
||||
@@ -1,14 +1,14 @@
|
||||
#############################
|
||||
__ __ _ _____
|
||||
\ \/ /___ _ __ / | |___ /
|
||||
\ // _ \ '_ \ | | |_ \
|
||||
/ \ __/ | | | | |_ ___) |
|
||||
/_/\_\___|_| |_| |_(_)____/
|
||||
|
||||
#############################
|
||||
###############################
|
||||
__ __ ____ ___
|
||||
\ \/ /___ _ __ |___ \ / _ \
|
||||
\ // _ \ '_ \ __) || | | |
|
||||
/ \ __/ | | | / __/ | |_| |
|
||||
/_/\_\___|_| |_| |_____(_)___/
|
||||
|
||||
###############################
|
||||
|
||||
University of Cambridge Computer Laboratory
|
||||
15 Jun 2004
|
||||
28 Aug 2004
|
||||
|
||||
http://www.cl.cam.ac.uk/netos/xen
|
||||
|
||||
@@ -149,10 +149,10 @@ Building Xen and XenLinux
|
||||
=========================
|
||||
|
||||
The public master BK repository for the 2.0 release lives at:
|
||||
bk://xen.bkbits.net/xeno-2.0.bk
|
||||
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/xeno-2.0.bk'
|
||||
'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
|
||||
@@ -164,8 +164,8 @@ can then install everything to the standard system directories
|
||||
|
||||
Take a look in install/boot/:
|
||||
install/boot/xen.gz The Xen 'kernel' (formerly image.gz)
|
||||
install/boot/vmlinuz-2.4.26-xen0 Domain 0 XenLinux kernel (xenolinux.gz)
|
||||
install/boot/vmlinuz-2.4.26-xenU Unprivileged XenLinux kernel
|
||||
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
|
||||
@@ -176,7 +176,7 @@ 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.26-xen0) which are essential for interpreting crash
|
||||
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
|
||||
@@ -185,7 +185,7 @@ 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.26.tar.gz make world") or by placing
|
||||
(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
|
||||
|
||||
@@ -1,15 +1,15 @@
|
||||
#############################
|
||||
__ __ _ _____
|
||||
\ \/ /___ _ __ / | |___ /
|
||||
\ // _ \ '_ \ | | |_ \
|
||||
/ \ __/ | | | | |_ ___) |
|
||||
/_/\_\___|_| |_| |_(_)____/
|
||||
|
||||
#############################
|
||||
###############################
|
||||
__ __ ____ ___
|
||||
\ \/ /___ _ __ |___ \ / _ \
|
||||
\ // _ \ '_ \ __) || | | |
|
||||
/ \ __/ | | | / __/ | |_| |
|
||||
/_/\_\___|_| |_| |_____(_)___/
|
||||
|
||||
XenDemoCD 1.3
|
||||
###############################
|
||||
|
||||
XenDemoCD 2.0
|
||||
University of Cambridge Computer Laboratory
|
||||
24 Jan 2004
|
||||
28 Aug 2004
|
||||
|
||||
http://www.cl.cam.ac.uk/netos/xen
|
||||
|
||||
@@ -18,10 +18,10 @@ Welcome to the Xen Demo CD!
|
||||
Executive Summary
|
||||
=================
|
||||
|
||||
This CD is a standalone demo of the Xen Virtual Machine Monitor (VMM)
|
||||
and Linux-2.4 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
|
||||
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.
|
||||
@@ -51,9 +51,9 @@ 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.26
|
||||
Xen / linux-2.4.26 using cmdline IP configuration
|
||||
Xen / linux-2.4.26 in "safe mode"
|
||||
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,
|
||||
@@ -119,7 +119,7 @@ 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/xeno-1.3, complete with BitKeeper
|
||||
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.
|
||||
|
||||
@@ -149,7 +149,7 @@ 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 xc_dom_create.py which
|
||||
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.
|
||||
|
||||
@@ -177,17 +177,13 @@ 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:
|
||||
|
||||
xc_dom_create.py -Dip=128.23.45.34,169.254.1.1 -Dmem=72
|
||||
xm create ip=128.23.45.34,169.254.1.1mem=72
|
||||
|
||||
[multiple variables may also be set with a single '-D' flag by
|
||||
separating them with ':'. Also, it's possible to use DNS hostnames
|
||||
rather than IP addresses.]
|
||||
|
||||
When invoked with the '-n' option xc_dom_create.py will do a dry run
|
||||
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]# xc_dom_create.py -D ip=commando-1.xeno,169.254.2.3 -Dmem=100
|
||||
[root@xendemo]# xm create -n ip=commando-1.xeno,169.254.2.3 mem=100
|
||||
Parsing config file 'defaults'
|
||||
|
||||
VM image : "/boot/xenlinux.gz"
|
||||
@@ -197,15 +193,15 @@ have e.g.:
|
||||
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"
|
||||
|
||||
xc_dom_create.py will print the local TCP port to which you should
|
||||
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 xc_dom_create.py, or add
|
||||
a terminal client is to specify '-c' to xm create, or add
|
||||
'auto_console=True' to the defaults file. This will cause
|
||||
xc_dom_create.py to automatically become the console terminal after
|
||||
'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'
|
||||
@@ -239,17 +235,18 @@ 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 xc_dom_control.py tool.
|
||||
You can manipulate running domains using the xm tool.
|
||||
Invoking it without arguments prints some usage information.
|
||||
|
||||
To see what domains are running, run 'xc_dom_control.py list'. Using the
|
||||
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 xc_dom_control.py, run the script with
|
||||
no arguments.
|
||||
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
|
||||
@@ -352,7 +349,7 @@ 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.22 OS image
|
||||
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
|
||||
@@ -400,9 +397,9 @@ config file.
|
||||
|
||||
A typical Grub menu option might look like:
|
||||
|
||||
title Xen / Xenlinux 2.4.26
|
||||
title Xen 2.0 / Xenlinux 2.4.27
|
||||
kernel /boot/xen.gz dom0_mem=131072 com1=115200 noht watchdog
|
||||
module /boot/vmlinuz-2.4.26-xen0 root=/dev/sda4 ro
|
||||
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
|
||||
@@ -421,7 +418,7 @@ require a second "module" line.
|
||||
Installing the Xen tools and source
|
||||
===================================
|
||||
|
||||
The tools and source live in the /usr/local/src/xen-2.0 directory on
|
||||
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.
|
||||
@@ -480,9 +477,10 @@ 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're
|
||||
probably better off in the long run doing a proper Redhat, Fedora,
|
||||
Debian etc install rather than just doing the hack described below:
|
||||
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.:
|
||||
@@ -529,7 +527,7 @@ 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-1.0/xeno-1.0.bk/tools/misc/miniterm/
|
||||
/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
|
||||
|
||||
@@ -1,10 +1,10 @@
|
||||
New console I/O infrastructure in Xen 1.3
|
||||
New console I/O infrastructure in Xen 2.0
|
||||
=========================================
|
||||
|
||||
Keir Fraser, University of Cambridge, 3rd June 2004
|
||||
|
||||
I thought I'd write a quick note about using the new console I/O
|
||||
infrastructure in Xen 1.3. Significant new features compared with 1.2,
|
||||
infrastructure in Xen 2.0. Significant new features compared with 1.2,
|
||||
and with older revisions of 1.3, include:
|
||||
- bi-directional console access
|
||||
- log in to a Xenolinux guest OS via its virtual console
|
||||
@@ -80,6 +80,6 @@ Virtual console for other domains
|
||||
# xencons localhost 9600
|
||||
|
||||
An alternative to manually running a terminal client is to specify
|
||||
'-c' to xc_dom_create.py, or add 'auto_console=True' to the defaults
|
||||
file. This will cause xc_dom_create.py to automatically become the
|
||||
'-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.
|
||||
+1
-1
@@ -15,7 +15,7 @@
|
||||
\vfill
|
||||
\begin{tabular}{l}
|
||||
{\Huge \bf Interface manual} \\[4mm]
|
||||
{\huge Xen v1.3 for x86} \\[80mm]
|
||||
{\huge Xen v2.0 for x86} \\[80mm]
|
||||
|
||||
{\Large Xen is Copyright (c) 2004, The Xen Team} \\[3mm]
|
||||
{\Large University of Cambridge, UK} \\[20mm]
|
||||
|
||||
+22
-18
@@ -77,7 +77,7 @@ following OSs have either been ported already or a port is in
|
||||
progress:
|
||||
\begin{itemize}
|
||||
\item Dragonfly BSD
|
||||
\item FreeBSD 4.8
|
||||
\item FreeBSD 5.3
|
||||
\item Linux 2.4
|
||||
\item Linux 2.6
|
||||
\item NetBSD 2.0
|
||||
@@ -85,8 +85,8 @@ progress:
|
||||
\item Windows XP
|
||||
\end{itemize}
|
||||
|
||||
Right now, Linux 2.4 and 2.6 are available for on Xen 2.0. NetBSD
|
||||
port will be updated to run on Xen 2.0, hopefully in time for the Xen
|
||||
Right now, Linux 2.4 and 2.6 are available for Xen 2.0. NetBSD
|
||||
port will be updated to run on Xen 2.0, hopefully in time for the NetBSD
|
||||
2.0 release. It is intended that Xen support be integrated into the
|
||||
official releases of Linux 2.6, NetBSD 2.0, FreeBSD and Dragonfly BSD.
|
||||
|
||||
@@ -289,16 +289,16 @@ line.
|
||||
\subsection{Using Bitkeeper}
|
||||
|
||||
The public master BK repository for the 2.0 release lives at: \\
|
||||
{\tt bk://xen.bkbits.net/xeno-unstable.bk}. You can use Bitkeeper to
|
||||
{\tt bk://xen.bkbits.net/xen-2.0.bk}. You can use Bitkeeper to
|
||||
download it and keep it updated with the latest features and fixes.
|
||||
|
||||
Change to the directory in which you want to put the source code, then
|
||||
run:
|
||||
\begin{verbatim}
|
||||
# bk clone bk://xen.bkbits.net/xeno-unstable.bk
|
||||
# bk clone bk://xen.bkbits.net/xeno-2.0.bk
|
||||
\end{verbatim}
|
||||
|
||||
Under your current directory, a new directory named 'xeno-unstable.bk'
|
||||
Under your current directory, a new directory named `xeno-2.0.bk'
|
||||
has been created, which contains all the source code for the Xen
|
||||
hypervisor and the Xen tools. The directory also contains `sparse'
|
||||
Linux source trees, containing only the files that differ between
|
||||
@@ -307,8 +307,8 @@ XenLinux and standard Linux.
|
||||
Once you have cloned the repository, you can update to the newest
|
||||
changes to the repository by running:
|
||||
\begin{verbatim}
|
||||
# cd xeno-unstable.bk # to change into the local repository
|
||||
# bk pull # to update the repository
|
||||
# cd xeno-2.0.bk # to change into the local repository
|
||||
# bk pull # to update the repository
|
||||
\end{verbatim}
|
||||
|
||||
\subsection{Without Bitkeeper}
|
||||
@@ -494,18 +494,22 @@ require a more complex setup, you will want to write a custom
|
||||
configuration file --- details of the configuration file formats are
|
||||
included in Chapter~\ref{cha:config}.
|
||||
|
||||
The \path{xmdefaults} file is a template description that is intended
|
||||
The \path{xmdefconfig1} file is a simple template configuration file
|
||||
for describing a single VM.
|
||||
|
||||
The \path{xmdefconfig2} file is a template description that is intended
|
||||
to be reused for multiple virtual machines. Setting the value of the
|
||||
{\tt vmid} variable fills in parts of this template.
|
||||
{\tt vmid} variable on the {\tt xm} command line
|
||||
fills in parts of this template.
|
||||
|
||||
\subsection{Editing \path{xmdefaults}}
|
||||
\subsection{Editing \path{xmdefconfig}}
|
||||
|
||||
At minimum, you should edit the following variables in \path{xmdefaults}:
|
||||
At minimum, you should edit the following variables in \path{xmdefconfig}:
|
||||
|
||||
\begin{description}
|
||||
\item[kernel] Set this to the path of the kernel you compiled for use
|
||||
with Xen. [e.g. {\tt kernel =
|
||||
'/root/xeno-unstable.bk/install/boot/vmlinuz-2.4.27-xenU'}]
|
||||
'/root/xeno-2.0.bk/install/boot/vmlinuz-2.4.27-xenU'}]
|
||||
\item[memory] Set this to the size of the domain's memory in
|
||||
megabytes. [e.g. {\tt memory = 64 } ]
|
||||
\item[disk] Set the first entry in this list to calculate the offset
|
||||
@@ -535,8 +539,8 @@ virtual machine with virtual machine ID 1.
|
||||
|
||||
The {\tt -c} switch causes {\tt xm} to turn into the domain's console
|
||||
after creation. The {\tt vmid=1} sets the {\tt vmid} variable used in
|
||||
the {\tt xmdefaults} file. The tool uses the
|
||||
\path{/etc/xen/xmdefaults} file, since no custom configuration file
|
||||
the {\tt xmdefconfig} file. The tool uses the
|
||||
\path{/etc/xen/xmdefconfig} file, since no custom configuration file
|
||||
was specified on the command line.
|
||||
|
||||
\chapter{Domain management tasks}
|
||||
@@ -678,7 +682,7 @@ Xen configuration files contain the following standard variables:
|
||||
\end{description}
|
||||
|
||||
It is also possible to include Python scripting commands in
|
||||
configuration files. This is done in the \path{xmdefaults} file in
|
||||
configuration files. This is done in the \path{xmdefconfig} file in
|
||||
order to handle the {\tt vmid} variable.
|
||||
|
||||
|
||||
@@ -743,7 +747,7 @@ The available {\em switches } and {\em arguments}are dependent on the
|
||||
declarations of the form {\tt variable=value} and may be used to set /
|
||||
override any of the values in the configuration file being used,
|
||||
including the standard variables described above and any custom
|
||||
variables (for instance, the \path{xmdefaults} file uses a {\tt vmid}
|
||||
variables (for instance, the \path{xmdefconfig} file uses a {\tt vmid}
|
||||
variable).
|
||||
|
||||
The available commands are as follows:
|
||||
@@ -1021,7 +1025,7 @@ IO privileges can be assigned to allow a domain to drive PCI devices
|
||||
itself. This is used for to support driver domains.
|
||||
|
||||
Setting backend privileges is currently only supported in SXP format
|
||||
config files (??? is this true - there's nothing in xmdefaults,
|
||||
config files (??? is this true - there's nothing in xmdefconfig,
|
||||
anyhow). To allow a domain to function as a backend for others,
|
||||
somewhere within the {\tt vm} element of its configuration file must
|
||||
be a {\tt backend} element of the form {\tt (backend ({\em type}))}
|
||||
|
||||
@@ -1,6 +1,6 @@
|
||||
|
||||
.section __xen_guest
|
||||
.asciz "GUEST_OS=linux,GUEST_VER=2.4,XEN_VER=1.3,VIRT_BASE=0xC0000000"
|
||||
.asciz "GUEST_OS=linux,GUEST_VER=2.4,XEN_VER=2.0,VIRT_BASE=0xC0000000"
|
||||
|
||||
.text
|
||||
#include <linux/config.h>
|
||||
|
||||
@@ -1,6 +1,6 @@
|
||||
|
||||
.section __xen_guest
|
||||
.asciz "GUEST_OS=linux,GUEST_VER=2.6,XEN_VER=1.3"
|
||||
.asciz "GUEST_OS=linux,GUEST_VER=2.6,XEN_VER=2.0"
|
||||
|
||||
.text
|
||||
#include <linux/config.h>
|
||||
|
||||
@@ -601,9 +601,9 @@ static int parseelfimage(char *elfbase,
|
||||
guestinfo = elfbase + shdr->sh_offset;
|
||||
|
||||
if ( (strstr(guestinfo, "GUEST_OS=linux") == NULL) ||
|
||||
(strstr(guestinfo, "XEN_VER=1.3") == NULL) )
|
||||
(strstr(guestinfo, "XEN_VER=2.0") == NULL) )
|
||||
{
|
||||
ERROR("Will only load Linux images built for Xen v1.3");
|
||||
ERROR("Will only load Linux images built for Xen v2.0");
|
||||
ERROR("Actually saw: '%s'", guestinfo);
|
||||
return -EINVAL;
|
||||
}
|
||||
|
||||
+3
-3
@@ -1,9 +1,9 @@
|
||||
|
||||
# This is the correct place to edit the build version.
|
||||
# All other places this is stored (eg. compile.h) should be autogenerated.
|
||||
export XEN_VERSION = 1
|
||||
export XEN_SUBVERSION = 3
|
||||
export XEN_EXTRAVERSION = "-devel"
|
||||
export XEN_VERSION = 2
|
||||
export XEN_SUBVERSION = 0
|
||||
export XEN_EXTRAVERSION = "-beta"
|
||||
|
||||
export BASEDIR := $(shell pwd)
|
||||
|
||||
|
||||
+2
-2
@@ -69,9 +69,9 @@ int parseelfimage(char *elfbase,
|
||||
printk("Xen-ELF header found: '%s'\n", guestinfo);
|
||||
|
||||
if ( (strstr(guestinfo, "GUEST_OS=linux") == NULL) ||
|
||||
(strstr(guestinfo, "XEN_VER=1.3") == NULL) )
|
||||
(strstr(guestinfo, "XEN_VER=2.0") == NULL) )
|
||||
{
|
||||
printk("ERROR: Xen will only load Linux built for Xen v1.3\n");
|
||||
printk("ERROR: Xen will only load Linux built for Xen v2.0\n");
|
||||
return -EINVAL;
|
||||
}
|
||||
|
||||
|
||||