mirror of
https://github.com/xen-project/xen.git
synced 2026-10-29 18:50:05 +01:00
bitkeeper revision 1.1159.1.356 (41893608s_lNTWHA0U6W3zyeQ6BCkg)
Merge ssh://srg//auto/groups/xeno/BK/xeno.bk into equilibrium.research:/export/scratch/xeno-docs.bk
This commit is contained in:
mwilli2@equilibrium.research committed
commit
5d87f44b9c
8 files changed
+226
-220
No files matched your search
@@ -12,9 +12,13 @@ SOURCEFORGE_MIRROR := http://heanet.dl.sourceforge.net/sourceforge
|
||||
#KERNELS = mk.linux-2.6-xen0 mk.linux-2.6-xenU mk.linux-2.4-xen0 mk.linux-2.4-xenU mk.netbsd-2.0-xenU
|
||||
KERNELS = mk.linux-2.6-xen0 mk.linux-2.6-xenU
|
||||
|
||||
ALLKERNELS = $(patsubst buildconfigs/%,%,$(wildcard buildconfigs/mk.*))
|
||||
ALLSPARSETREES = $(patsubst %-xen-sparse,%,$(wildcard *-xen-sparse))
|
||||
|
||||
export INSTALL_DIR SOURCEFORGE_MIRROR
|
||||
|
||||
.PHONY: all dist install xen tools kernels docs kdelete kclean mkpatches world clean mrproper
|
||||
.PHONY: all dist install xen tools kernels docs world clean mkpatches mrproper
|
||||
.PHONY: kbuild kdelete kclean
|
||||
|
||||
all: dist
|
||||
|
||||
@@ -49,17 +53,19 @@ docs:
|
||||
sh ./docs/check_pkgs && \
|
||||
$(MAKE) prefix=$(INSTALL_DIR) dist=yes -C docs install || true
|
||||
|
||||
kbuild: kernels
|
||||
|
||||
# Delete the kernel build trees entirely
|
||||
kdelete:
|
||||
for i in $(KERNELS) ; do $(MAKE) -f buildconfigs/$$i delete ; done
|
||||
|
||||
# Clean the kernel build trees
|
||||
kclean:
|
||||
for i in $(KERNELS) ; do $(MAKE) -f buildconfigs/$$i delete ; done
|
||||
for i in $(KERNELS) ; do $(MAKE) -f buildconfigs/$$i clean ; done
|
||||
|
||||
# Make patches from kernel sparse trees
|
||||
mkpatches:
|
||||
$(MAKE) -f buildconfigs/Rules.mk mkpatches
|
||||
for i in $(ALLSPARSETREES) ; do $(MAKE) -f buildconfigs/Rules.mk $$i-xen.patch ; done
|
||||
|
||||
|
||||
# build xen, the tools, and a domain 0 plus unprivileged linux-xen images,
|
||||
@@ -77,9 +83,10 @@ clean:
|
||||
$(MAKE) -C docs clean
|
||||
|
||||
# clean, but blow away kernel build tree plus tar balls
|
||||
mrproper: clean kdelete
|
||||
rm -rf dist patches *.tar.bz2
|
||||
$(MAKE) -f buildconfigs/Rules.mk mrproper
|
||||
mrproper: clean
|
||||
rm -rf dist patches
|
||||
for i in $(ALLKERNELS) ; do $(MAKE) -f buildconfigs/$$i delete ; done
|
||||
for i in $(ALLSPARSETREES) ; do $(MAKE) -f buildconfigs/Rules.mk $$i-mrproper ; done
|
||||
|
||||
install-twisted:
|
||||
wget http://www.twistedmatrix.com/products/get-current.epy
|
||||
|
||||
+50
-62
@@ -1,80 +1,68 @@
|
||||
|
||||
# We expect these two to already be set if people
|
||||
# are using the top-level Makefile
|
||||
DIST_DIR ?= $(shell pwd)/dist
|
||||
INSTALL_DIR ?= $(DIST_DIR)/install
|
||||
DIST_DIR ?= $(shell pwd)/dist
|
||||
INSTALL_DIR ?= $(DIST_DIR)/install
|
||||
|
||||
.PHONY: mkpatches mrproper
|
||||
|
||||
|
||||
# Figure out which Linux version
|
||||
LINUX_26VER ?= $(shell ( /bin/ls -ld linux-2.6.*-xen-sparse ) \
|
||||
2>/dev/null | sed -e 's!^.*linux-\(.\+\)-xen-sparse!\1!' )
|
||||
|
||||
LINUX_24VER ?= $(shell ( /bin/ls -ld linux-2.4.*-xen-sparse ) \
|
||||
2>/dev/null | sed -e 's!^.*linux-\(.\+\)-xen-sparse!\1!' )
|
||||
# Expand Linux series to Linux version
|
||||
LINUX_SERIES ?= 2.6
|
||||
LINUX_VER ?= $(patsubst linux-%-xen-sparse,%,$(wildcard linux-$(LINUX_SERIES)*-xen-sparse))
|
||||
|
||||
LINUX_SRC_PATH ?= .:..
|
||||
# Setup Linux search patch
|
||||
LINUX_SRC_PATH ?= .:..
|
||||
vpath linux-%.tar.bz2 $(LINUX_SRC_PATH)
|
||||
|
||||
LINUX_26SRC ?= $(firstword $(foreach dir,$(subst :, ,$(LINUX_SRC_PATH)),\
|
||||
$(wildcard $(dir)/linux-$(LINUX_26VER).tar.*z*)))
|
||||
# download a pristine Linux kernel tarball if there isn't one in LINUX_SRC_PATH
|
||||
linux-%.tar.bz2: override _LINUX_VDIR = $(word 1,$(subst ., ,$*)).$(word 2,$(subst ., ,$*))
|
||||
linux-%.tar.bz2:
|
||||
echo "Cannot find linux-$*.tar.bz2 in path $(LINUX_SRC_PATH)"
|
||||
wget http://www.kernel.org/pub/linux/kernel/v$(_LINUX_VDIR)/linux-$*.tar.bz2 -O./$@
|
||||
|
||||
LINUX_24SRC ?= $(firstword $(foreach dir,$(subst :, ,$(LINUX_SRC_PATH)),\
|
||||
$(wildcard $(dir)/linux-$(LINUX_24VER).tar.*z*)))
|
||||
|
||||
.PHONY: mkpatches linux-$(LINUX_24VER)-xen.patch linux-$(LINUX_26VER)-xen.patch mrproper
|
||||
|
||||
# search for a pristine kernel tar ball, or try downloading one
|
||||
linux-$(LINUX_26VER).tar.bz2:
|
||||
ifeq ($(LINUX_26SRC),)
|
||||
echo "Cannot find linux-$(LINUX_26VER).tar.bz2 in path $(LINUX_SRC_PATH)"
|
||||
wget http://www.kernel.org/pub/linux/kernel/v2.6/linux-$(LINUX_26VER).tar.bz2 -O./linux-$(LINUX_26VER).tar.bz2
|
||||
LINUX_26SRC := ./linux-$(LINUX_26VER).tar.bz2
|
||||
endif
|
||||
# Expand NetBSD release to NetBSD version
|
||||
NETBSD_RELEASE ?= 2.0
|
||||
NETBSD_VER ?= $(patsubst netbsd-%-xen-sparse,%,$(wildcard netbsd-$(NETBSD_RELEASE)*-xen-sparse))
|
||||
NETBSD_CVSSNAP ?= 20040906
|
||||
|
||||
pristine-linux-$(LINUX_26VER): $(LINUX_26SRC)
|
||||
rm -rf tmp-linux-$(LINUX_26VER) $@ && \
|
||||
mkdir -p tmp-linux-$(LINUX_26VER) && \
|
||||
tar -C tmp-linux-$(LINUX_26VER) -jxf $(LINUX_26SRC) && \
|
||||
mv tmp-linux-$(LINUX_26VER)/* $@
|
||||
# Setup NetBSD search patch
|
||||
NETBSD_SRC_PATH ?= .:..
|
||||
vpath netbsd-%.tar.bz2 $(NETBSD_SRC_PATH)
|
||||
|
||||
# download a pristine NetBSD tarball if there isn't one in NETBSD_SRC_PATH
|
||||
netbsd-%-xen-kernel-$(NETBSD_CVSSNAP).tar.bz2:
|
||||
echo "Cannot find $@ in path $(NETBSD_SRC_PATH)"
|
||||
wget http://www.cl.cam.ac.uk/Research/SRG/netos/xen/downloads/netbsd-$(NETBSD_VER)-xen-kernel-$(NETBSD_CVSSNAP).tar.bz2 -O./$@
|
||||
|
||||
netbsd-%.tar.bz2: netbsd-%-xen-kernel-$(NETBSD_CVSSNAP).tar.bz2
|
||||
ln -fs $< $@
|
||||
|
||||
|
||||
|
||||
|
||||
pristine-%: %.tar.bz2
|
||||
rm -rf tmp-$* $@ && \
|
||||
mkdir -p tmp-$* && \
|
||||
tar -C tmp-$* -jxf $< && \
|
||||
mv tmp-$*/* $@
|
||||
touch $@ # update timestamp to avoid rebuild
|
||||
@rm -rf tmp-linux-$(LINUX_26VER)
|
||||
@rm -rf tmp-$*
|
||||
|
||||
|
||||
# search for a pristine kernel tar ball, or try downloading one
|
||||
linux-$(LINUX_24VER).tar.bz2:
|
||||
ifeq ($(LINUX_24SRC),)
|
||||
echo "Cannot find linux-$(LINUX_24VER).tar.bz2 in path $(LINUX_SRC_PATH)"
|
||||
wget http://www.kernel.org/pub/linux/kernel/v2.4/linux-$(LINUX_24VER).tar.bz2 -O./linux-$(LINUX_24VER).tar.bz2
|
||||
LINUX_24SRC := ./linux-$(LINUX_24VER).tar.bz2
|
||||
endif
|
||||
|
||||
pristine-linux-$(LINUX_24VER): $(LINUX_24SRC)
|
||||
rm -rf tmp-linux-$(LINUX_24VER) $@ && \
|
||||
mkdir -p tmp-linux-$(LINUX_24VER) && \
|
||||
tar -C tmp-linux-$(LINUX_24VER) -jxf $(LINUX_24SRC) && \
|
||||
mv tmp-linux-$(LINUX_24VER)/* $@ && \
|
||||
touch $@ # update timestamp to avoid rebuild
|
||||
@rm -rf tmp-linux-$(LINUX_24VER)
|
||||
|
||||
linux-$(LINUX_24VER)-xen.patch: pristine-linux-$(LINUX_24VER)
|
||||
%-xen.patch: pristine-%
|
||||
rm -rf tmp-$@
|
||||
cp -al pristine-linux-$(LINUX_24VER) tmp-$@
|
||||
( cd linux-$(LINUX_24VER)-xen-sparse ; \
|
||||
./mkbuildtree ../tmp-$@ )
|
||||
diff -Nurp pristine-linux-$(LINUX_24VER) tmp-$@ > $@ || true
|
||||
cp -al pristine-$* tmp-$@
|
||||
( cd $*-xen-sparse && ./mkbuildtree ../tmp-$@ )
|
||||
diff -Nurp pristine-$* tmp-$@ > $@ || true
|
||||
rm -rf tmp-$@
|
||||
|
||||
linux-$(LINUX_26VER)-xen.patch: pristine-linux-$(LINUX_26VER)
|
||||
rm -rf tmp-$@
|
||||
cp -al pristine-linux-$(LINUX_26VER) tmp-$@
|
||||
( cd linux-$(LINUX_26VER)-xen-sparse ; \
|
||||
./mkbuildtree ../tmp-$@ )
|
||||
diff -Nurp pristine-linux-$(LINUX_26VER) tmp-$@ > $@ || true
|
||||
rm -rf tmp-$@
|
||||
%-mrproper:
|
||||
rm -rf pristine-$* $*.tar.bz2
|
||||
rm -rf $*-xen.patch
|
||||
rm -rf $*-tools $*-tools.tar.bz2
|
||||
|
||||
mkpatches: linux-$(LINUX_24VER)-xen.patch linux-$(LINUX_26VER)-xen.patch
|
||||
|
||||
mrproper:
|
||||
rm -rf pristine-linux-$(LINUX_24VER) linux-$(LINUX_24VER).tar.bz2
|
||||
rm -rf pristine-linux-$(LINUX_26VER) linux-$(LINUX_26VER).tar.bz2
|
||||
rm -rf linux-$(LINUX_24VER)-xen.patch linux-$(LINUX_26VER)-xen.patch
|
||||
rm -rf pristine-netbsd-2.0 netbsd-2.0-tools
|
||||
# never delete any intermediate files.
|
||||
.SECONDARY:
|
||||
@@ -1,7 +1,9 @@
|
||||
|
||||
LINUX_SERIES = 2.4
|
||||
|
||||
EXTRAVERSION = xen0
|
||||
|
||||
FULLVERSION = $(LINUX_24VER)-$(EXTRAVERSION)
|
||||
FULLVERSION = $(LINUX_VER)-$(EXTRAVERSION)
|
||||
|
||||
LINUX_DIR = linux-$(FULLVERSION)
|
||||
|
||||
@@ -19,11 +21,11 @@ patches/ebtables.diff:
|
||||
mkdir -p patches
|
||||
wget http://www.cl.cam.ac.uk/netos/xen/downloads/ebtables-brnf-5_vs_2.4.27.diff.gz -O- | gunzip -c > $@
|
||||
|
||||
$(LINUX_DIR): pristine-linux-$(LINUX_24VER) patches/ebtables.diff
|
||||
$(LINUX_DIR): pristine-linux-$(LINUX_VER) patches/ebtables.diff
|
||||
rm -rf $(LINUX_DIR)
|
||||
cp -al pristine-linux-$(LINUX_24VER) $(LINUX_DIR)
|
||||
cp -al pristine-linux-$(LINUX_VER) $(LINUX_DIR)
|
||||
# Apply arch-xen patches
|
||||
( cd linux-$(LINUX_24VER)-xen-sparse ; \
|
||||
( cd linux-$(LINUX_VER)-xen-sparse ; \
|
||||
./mkbuildtree ../$(LINUX_DIR) )
|
||||
# Patch kernel Makefile to set EXTRAVERSION
|
||||
( cd $(LINUX_DIR) ; \
|
||||
@@ -40,11 +42,4 @@ clean:
|
||||
$(MAKE) -C $(LINUX_DIR) ARCH=xen clean
|
||||
|
||||
delete:
|
||||
rm -rf tmp-linux-$(LINUX_24VER) $(LINUX_DIR)
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
rm -rf tmp-linux-$(LINUX_VER) $(LINUX_DIR)
|
||||
@@ -1,7 +1,9 @@
|
||||
|
||||
LINUX_SERIES = 2.4
|
||||
|
||||
EXTRAVERSION = xenU
|
||||
|
||||
FULLVERSION = $(LINUX_24VER)-$(EXTRAVERSION)
|
||||
FULLVERSION = $(LINUX_VER)-$(EXTRAVERSION)
|
||||
|
||||
LINUX_DIR = linux-$(FULLVERSION)
|
||||
|
||||
@@ -19,11 +21,11 @@ patches/ebtables.diff:
|
||||
mkdir -p patches
|
||||
wget http://www.cl.cam.ac.uk/netos/xen/downloads/ebtables-brnf-5_vs_2.4.27.diff.gz -O- | gunzip -c > $@
|
||||
|
||||
$(LINUX_DIR): pristine-linux-$(LINUX_24VER) patches/ebtables.diff
|
||||
$(LINUX_DIR): pristine-linux-$(LINUX_VER) patches/ebtables.diff
|
||||
rm -rf $(LINUX_DIR)
|
||||
cp -al pristine-linux-$(LINUX_24VER) $(LINUX_DIR)
|
||||
cp -al pristine-linux-$(LINUX_VER) $(LINUX_DIR)
|
||||
# Apply arch-xen patches
|
||||
( cd linux-$(LINUX_24VER)-xen-sparse ; \
|
||||
( cd linux-$(LINUX_VER)-xen-sparse ; \
|
||||
./mkbuildtree ../$(LINUX_DIR) )
|
||||
# Patch kernel Makefile to set EXTRAVERSION
|
||||
( cd $(LINUX_DIR) ; \
|
||||
@@ -38,11 +40,4 @@ clean:
|
||||
$(MAKE) -C $(LINUX_DIR) ARCH=xen clean
|
||||
|
||||
delete:
|
||||
rm -rf tmp-linux-$(LINUX_24VER) $(LINUX_DIR)
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
rm -rf tmp-linux-$(LINUX_VER) $(LINUX_DIR)
|
||||
@@ -1,7 +1,9 @@
|
||||
|
||||
LINUX_SERIES = 2.6
|
||||
|
||||
EXTRAVERSION = xen0
|
||||
|
||||
FULLVERSION = $(LINUX_26VER)-$(EXTRAVERSION)
|
||||
FULLVERSION = $(LINUX_VER)-$(EXTRAVERSION)
|
||||
|
||||
LINUX_DIR = linux-$(FULLVERSION)
|
||||
|
||||
@@ -15,11 +17,11 @@ build: $(LINUX_DIR)
|
||||
$(MAKE) -C $(LINUX_DIR) ARCH=xen INSTALL_PATH=$(INSTALL_DIR) install
|
||||
|
||||
# The real action starts here!
|
||||
$(LINUX_DIR): pristine-linux-$(LINUX_26VER)
|
||||
$(LINUX_DIR): pristine-linux-$(LINUX_VER)
|
||||
rm -rf $(LINUX_DIR)
|
||||
cp -al pristine-linux-$(LINUX_26VER) $(LINUX_DIR)
|
||||
cp -al pristine-linux-$(LINUX_VER) $(LINUX_DIR)
|
||||
# Apply arch-xen patches
|
||||
( cd linux-$(LINUX_26VER)-xen-sparse ; \
|
||||
( cd linux-$(LINUX_VER)-xen-sparse ; \
|
||||
./mkbuildtree ../$(LINUX_DIR) )
|
||||
# Patch kernel Makefile to set EXTRAVERSION
|
||||
( cd $(LINUX_DIR) ; \
|
||||
@@ -33,11 +35,4 @@ clean:
|
||||
$(MAKE) -C $(LINUX_DIR) ARCH=xen clean
|
||||
|
||||
delete:
|
||||
rm -rf tmp-linux-$(LINUX_26VER) $(LINUX_DIR)
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
rm -rf tmp-linux-$(LINUX_VER) $(LINUX_DIR)
|
||||
@@ -1,7 +1,9 @@
|
||||
|
||||
LINUX_SERIES = 2.6
|
||||
|
||||
EXTRAVERSION = xenU
|
||||
|
||||
FULLVERSION = $(LINUX_26VER)-$(EXTRAVERSION)
|
||||
FULLVERSION = $(LINUX_VER)-$(EXTRAVERSION)
|
||||
|
||||
LINUX_DIR = linux-$(FULLVERSION)
|
||||
|
||||
@@ -16,11 +18,11 @@ build: $(LINUX_DIR)
|
||||
$(MAKE) -C $(LINUX_DIR) ARCH=xen INSTALL_PATH=$(INSTALL_DIR) install
|
||||
|
||||
|
||||
$(LINUX_DIR): pristine-linux-$(LINUX_26VER)
|
||||
$(LINUX_DIR): pristine-linux-$(LINUX_VER)
|
||||
rm -rf $(LINUX_DIR)
|
||||
cp -al pristine-linux-$(LINUX_26VER) $(LINUX_DIR)
|
||||
cp -al pristine-linux-$(LINUX_VER) $(LINUX_DIR)
|
||||
# Apply arch-xen patches
|
||||
( cd linux-$(LINUX_26VER)-xen-sparse ; \
|
||||
( cd linux-$(LINUX_VER)-xen-sparse ; \
|
||||
./mkbuildtree ../$(LINUX_DIR) )
|
||||
# Patch kernel Makefile to set EXTRAVERSION
|
||||
( cd $(LINUX_DIR) ; \
|
||||
@@ -34,11 +36,4 @@ clean:
|
||||
$(MAKE) -C $(LINUX_DIR) ARCH=xen clean
|
||||
|
||||
delete:
|
||||
rm -rf tmp-linux-$(LINUX_26VER) $(LINUX_DIR)
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
rm -rf tmp-linux-$(LINUX_VER) $(LINUX_DIR)
|
||||
@@ -1,5 +1,6 @@
|
||||
|
||||
NETBSD_RELEASE ?= 2.0
|
||||
NETBSD_CVSSNAP ?= 20040906
|
||||
|
||||
EXTRAVERSION = xenU
|
||||
|
||||
@@ -11,40 +12,19 @@ NETBSD_DIR = netbsd-$(FULLVERSION)
|
||||
|
||||
include buildconfigs/Rules.mk
|
||||
|
||||
NETBSD_VER ?= $(shell ( /bin/ls -ld netbsd-$(NETBSD_RELEASE)*-xen-sparse ) 2>/dev/null | \
|
||||
sed -e 's!^.*netbsd-\(.\+\)-xen-sparse!\1!' )
|
||||
NETBSD_CVSSNAP ?= 20040906
|
||||
NETBSD_SRC_PATH ?= .:..
|
||||
NETBSD_SRC ?= $(firstword $(foreach dir,$(subst :, ,$(NETBSD_SRC_PATH)),\
|
||||
$(wildcard $(dir)/netbsd-$(NETBSD_VER)-xen-kernel-$(NETBSD_CVSSNAP).tar.*z*)))
|
||||
build: $(NETBSD_DIR) netbsd-$(EXTRAVERSION)
|
||||
|
||||
NETBSD_TOOLS_SRC ?= $(firstword $(foreach dir,$(subst :, ,$(NETBSD_SRC_PATH)),\
|
||||
$(wildcard $(dir)/netbsd-$(NETBSD_VER)-tools.tar.*z*)))
|
||||
|
||||
build: $(NETBSD_DIR) netbsd-$(EXTRAVERSION)
|
||||
|
||||
netbsd-$(NETBSD_VER)-xen-kernel-$(NETBSD_CVSSNAP).tar.bz2:
|
||||
ifeq ($(NETBSD_SRC),)
|
||||
@echo "Cannot find netbsd-$(NETBSD_VER)-xen-kernel-$(NETBSD_CVSSNAP).tar.gz in path $(NETBSD_SRC_PATH)"
|
||||
@wget http://www.cl.cam.ac.uk/Research/SRG/netos/xen/downloads/netbsd-$(NETBSD_VER)-xen-kernel-$(NETBSD_CVSSNAP).tar.bz2 -O./netbsd-$(NETBSD_VER)-xen-kernel-$(NETBSD_CVSSNAP).tar.bz2
|
||||
NETBSD_SRC := ./netbsd-$(NETBSD_VER)-xen-kernel-$(NETBSD_CVSSNAP).tar.bz2
|
||||
endif
|
||||
|
||||
pristine-netbsd-$(NETBSD_VER): $(NETBSD_SRC)
|
||||
rm -rf tmp-netbsd-$(NETBSD_VER) $@ && \
|
||||
mkdir -p tmp-netbsd-$(NETBSD_VER) && \
|
||||
tar -C tmp-netbsd-$(NETBSD_VER) -jxf $(NETBSD_SRC) && \
|
||||
mv tmp-netbsd-$(NETBSD_VER)/* $@
|
||||
touch $@ # update timestamp to avoid rebuild
|
||||
@rm -rf tmp-netbsd-$(NETBSD_VER)
|
||||
|
||||
pristine-netbsd-tools-src:
|
||||
netbsd-tools-src:
|
||||
ifeq ($(NETBSD_TOOLS_SRC),)
|
||||
@echo "Cannot find netbsd-$(NETBSD_VER)-tools.tar.gz in path $(NETBSD_SRC_PATH)"
|
||||
@wget http://www.cl.cam.ac.uk/Research/SRG/netos/xen/downloads/netbsd-$(NETBSD_VER)-tools.tar.bz2 -O./netbsd-$(NETBSD_VER)-tools.tar.bz2
|
||||
NETBSD_TOOLS_SRC := ./netbsd-$(NETBSD_VER)-tools.tar.bz2
|
||||
endif
|
||||
|
||||
netbsd-tools: pristine-netbsd-tools-src
|
||||
netbsd-tools: netbsd-tools-src
|
||||
@[ -d netbsd-$(NETBSD_RELEASE)-tools ] || { \
|
||||
echo extract $(NETBSD_TOOLS_SRC); \
|
||||
tar -jxf $(NETBSD_TOOLS_SRC); }
|
||||
@@ -60,7 +40,7 @@ $(NETBSD_DIR): netbsd-tools pristine-netbsd-$(NETBSD_VER)
|
||||
netbsd-xen%:
|
||||
$(MAKE) -C netbsd-$(FULLVERSION) config
|
||||
$(MAKE) -C netbsd-$(FULLVERSION) netbsd
|
||||
$(MAKE) -C netbsd-$(FULLVERSION) INSTALL_PATH=$(INSTALL_DIR) INSTALL_NAME=boot/netbsd-$(NETBSD_VER)-$(subst netbsd-,,$@) install
|
||||
$(MAKE) -C netbsd-$(FULLVERSION) INSTALL_PATH=$(INSTALL_DIR) INSTALL_NAME=boot/netbsd-$(NETBSD_VER)-xen$* install
|
||||
|
||||
clean:
|
||||
$(MAKE) -C netbsd-$(FULLVERSION) clean
|
||||
|
||||
+129
-78
@@ -352,120 +352,171 @@ and loading its kernel image at the appropriate virtual address.
|
||||
|
||||
|
||||
|
||||
\chapter{Network I/O}
|
||||
\chapter{Devices}
|
||||
|
||||
Devices such as network and disk are exported to guests using a
|
||||
split device driver. The device driver domain, which accesses the
|
||||
physical device directly also runs a {\em backend} driver, serving
|
||||
requests to that device from guests. Each guest will use a simple
|
||||
{\em frontend} driver, to access the backend. Communication between these
|
||||
domains is composed of two parts: First, data is placed onto a shared
|
||||
memory page between the domains. Second, an event channel between the
|
||||
two domains is used to pass notification that data is outstanding.
|
||||
This separation of notification from data transfer allows message
|
||||
batching, and results in very efficient device access. Specific
|
||||
details on inter-domain communication are available in
|
||||
Appendix~\ref{s:idc}.
|
||||
|
||||
This chapter provides details on some individual device interfaces
|
||||
available to Xen guests.
|
||||
|
||||
\section{Network I/O}
|
||||
|
||||
Virtual network device services are provided by shared memory
|
||||
communications with a `backend' domain. From the point of view of
|
||||
communications with a backend domain. From the point of view of
|
||||
other domains, the backend may be viewed as a virtual ethernet switch
|
||||
element with each domain having one or more virtual network interfaces
|
||||
connected to it.
|
||||
|
||||
\section{Backend Packet Handling}
|
||||
The backend driver is responsible primarily for {\it data-path} operations.
|
||||
In terms of networking this means packet transmission and reception.
|
||||
\subsection{Backend Packet Handling}
|
||||
|
||||
The backend driver is responsible for a variety of actions relating to
|
||||
the transmission and reception of packets from the physical device.
|
||||
With regard to transmission, the backend performs these key actions:
|
||||
|
||||
On the transmission side, the backend needs to perform two key actions:
|
||||
\begin{itemize}
|
||||
\item {\tt Validation:} A domain may only be allowed to emit packets
|
||||
matching a certain specification; for example, ones in which the
|
||||
source IP address matches one assigned to the virtual interface over
|
||||
which it is sent. The backend would be responsible for ensuring any
|
||||
such requirements are met, either by checking or by stamping outgoing
|
||||
packets with prescribed values for certain fields.
|
||||
\item {\bf Validation:} To ensure that domains do not attempt to
|
||||
generate invalid (e.g. spoofed) traffic, the backend driver may
|
||||
validate headers ensuring that source MAC and IP addresses match the
|
||||
interface that they have been sent from.
|
||||
|
||||
Validation functions can be configured using standard firewall rules
|
||||
(i.e. IP Tables, in the case of Linux).
|
||||
|
||||
\item {\tt Scheduling:} Since a number of domains can share a single
|
||||
``real'' network interface, the hypervisor must mediate access when
|
||||
several domains each have packets queued for transmission. Of course,
|
||||
this general scheduling function subsumes basic shaping or
|
||||
rate-limiting schemes.
|
||||
|
||||
\item {\tt Logging and Accounting:} The hypervisor can be configured
|
||||
with classifier rules that control how packets are accounted or
|
||||
logged. For example, {\it domain0} could request that it receives a
|
||||
log message or copy of the packet whenever another domain attempts to
|
||||
send a TCP packet containg a SYN.
|
||||
Validation functions can be configured using standard firewall rules
|
||||
({\small{\tt iptables}} in the case of Linux).
|
||||
|
||||
\item {\bf Scheduling:} Since a number of domains can share a single
|
||||
physical network interface, the backend must mediate access when
|
||||
several domains each have packets queued for transmission. This
|
||||
general scheduling function subsumes basic shaping or rate-limiting
|
||||
schemes.
|
||||
|
||||
\item {\bf Logging and Accounting:} The backend domain can be
|
||||
configured with classifier rules that control how packets are
|
||||
accounted or logged. For example, log messages might be generated
|
||||
whenever a domain attempts to send a TCP packet containing a SYN.
|
||||
\end{itemize}
|
||||
|
||||
On the recive side, the backend's role is relatively straightforward:
|
||||
once a packet is received, it just needs to determine the virtual interface(s)
|
||||
to which it must be delivered and deliver it via page-flipping.
|
||||
On receipt of incoming packets, the backend acts as a simple
|
||||
demultiplexer: Packets are passed to the appropriate virtual
|
||||
interface after any necessary logging and accounting have been carried
|
||||
out.
|
||||
|
||||
|
||||
\section{Data Transfer}
|
||||
\subsection{Data Transfer}
|
||||
|
||||
Each virtual interface uses two ``descriptor rings'', one for transmit,
|
||||
the other for receive. Each descriptor identifies a block of contiguous
|
||||
physical memory allocated to the domain. There are four cases:
|
||||
physical memory allocated to the domain.
|
||||
|
||||
\begin{itemize}
|
||||
The transmit ring carries packets to transmit from the guest to the
|
||||
backend domain. The return path of the transmit ring carries messages
|
||||
indicating that the contents have been physically transmitted and the
|
||||
backend no longer requires the associated pages of memory.
|
||||
|
||||
\item The transmit ring carries packets to transmit from the domain to the
|
||||
hypervisor.
|
||||
To receive packets, the guest places descriptors of unused pages on
|
||||
the receive ring. The backend will return received packets by
|
||||
exchanging these pages in the domain's memory with new pages
|
||||
containing the received data, and passing back descriptors regarding
|
||||
the new packets on the ring. This zero-copy approach allows the
|
||||
backend to maintain a pool of free pages to receive packets into, and
|
||||
then deliver them to appropriate domains after examining their
|
||||
headers.
|
||||
|
||||
\item The return path of the transmit ring carries ``empty'' descriptors
|
||||
indicating that the contents have been transmitted and the memory can be
|
||||
re-used.
|
||||
|
||||
\item The receive ring carries empty descriptors from the domain to the
|
||||
hypervisor; these provide storage space for that domain's received packets.
|
||||
|
||||
\item The return path of the receive ring carries packets that have been
|
||||
received.
|
||||
\end{itemize}
|
||||
|
||||
Real physical addresses are used throughout, with the domain performing
|
||||
translation from pseudo-physical addresses if that is necessary.
|
||||
%
|
||||
%Real physical addresses are used throughout, with the domain performing
|
||||
%translation from pseudo-physical addresses if that is necessary.
|
||||
|
||||
If a domain does not keep its receive ring stocked with empty buffers then
|
||||
packets destined to it may be dropped. This provides some defense against
|
||||
receiver-livelock problems because an overload domain will cease to receive
|
||||
packets destined to it may be dropped. This provides some defence against
|
||||
receive livelock problems because an overload domain will cease to receive
|
||||
further data. Similarly, on the transmit path, it provides the application
|
||||
with feedback on the rate at which packets are able to leave the system.
|
||||
|
||||
Synchronization between the hypervisor and the domain is achieved using
|
||||
counters held in shared memory that is accessible to both. Each ring has
|
||||
associated producer and consumer indices indicating the area in the ring
|
||||
that holds descriptors that contain data. After receiving {\it n} packets
|
||||
or {\t nanoseconds} after receiving the first packet, the hypervisor sends
|
||||
an event to the domain.
|
||||
|
||||
\chapter{Block I/O}
|
||||
Flow control on rings is achieved by including a pair of producer
|
||||
indexes on the shared ring page. Each side will maintain a private
|
||||
consumer index indicating the next outstanding message. In this
|
||||
manner, the domains cooperate to divide the ring into two message
|
||||
lists, one in each direction. Notification is decoupled from the
|
||||
immediate placement of new messages on the ring; the event channel
|
||||
will be used to generate notification when {\em either} a certain
|
||||
number of outstanding messages are queued, {\em or} a specified number
|
||||
of nanoseconds have elapsed since the oldest message was placed on the
|
||||
ring.
|
||||
|
||||
\section{Virtual Block Devices (VBDs)}
|
||||
% Not sure if my version is any better -- here is what was here before:
|
||||
%% Synchronization between the backend domain and the guest is achieved using
|
||||
%% counters held in shared memory that is accessible to both. Each ring has
|
||||
%% associated producer and consumer indices indicating the area in the ring
|
||||
%% that holds descriptors that contain data. After receiving {\it n} packets
|
||||
%% or {\t nanoseconds} after receiving the first packet, the hypervisor sends
|
||||
%% an event to the domain.
|
||||
|
||||
All guest OS disk access goes through the VBD interface. The VBD
|
||||
interface provides the administrator with the ability to selectively
|
||||
grant domains access to portions of block storage devices visible to
|
||||
the the block backend device (usually domain 0).
|
||||
\section{Block I/O}
|
||||
|
||||
VBDs can literally be backed by any block device accessible to the
|
||||
backend domain, including network-based block devices (iSCSI, *NBD,
|
||||
etc), loopback devices and LVM / MD devices.
|
||||
All guest OS disk access goes through the virtual block device VBD
|
||||
interface. This interface allows domains access to portions of block
|
||||
storage devices visible to the the block backend device. The VBD
|
||||
interface is a split driver, similar to the network interface
|
||||
described above. A single shared memory ring is used between the
|
||||
frontend and backend drivers, across which read and write messages are
|
||||
sent.
|
||||
|
||||
Any block device accessible to the backend domain, including
|
||||
network-based block (iSCSI, *NBD, etc), loopback and LVM/MD devices,
|
||||
can be exported as a VBD. Each VBD is mapped to a device node in the
|
||||
guest, specified in the guest's startup configuration.
|
||||
|
||||
Old (Xen 1.2) virtual disks are not supported under Xen 2.0, since
|
||||
similar functionality can be achieved using the (more advanced) LVM
|
||||
system, which is already in widespread use.
|
||||
|
||||
\subsection{Data Transfer}
|
||||
Domains which have been granted access to a logical block device are permitted
|
||||
to read and write it by shared memory communications with the backend domain.
|
||||
|
||||
In overview, the same style of descriptor-ring that is used for
|
||||
network packets is used here. Each domain has one ring that carries
|
||||
operation requests to the hypervisor and carries the results back
|
||||
again.
|
||||
The single ring between the guest and the block backend supports three
|
||||
messages:
|
||||
|
||||
Rather than copying data, the backend simply maps the domain's buffers
|
||||
in order to enable direct DMA to them. The act of mapping the buffers
|
||||
also increases the reference counts of the underlying pages, so that
|
||||
the unprivileged domain cannot try to return them to the hypervisor,
|
||||
install them as page tables, or any other unsafe behaviour.
|
||||
%block API here
|
||||
\begin{description}
|
||||
\item [{\small {\tt PROBE}}:] Return a list of the VBDs available to this guest
|
||||
from the backend. The request includes a descriptor of a free page
|
||||
into which the reply will be written by the backend.
|
||||
|
||||
\chapter{Privileged operations}
|
||||
\item [{\small {\tt READ}}:] Read data from the specified block device. The
|
||||
front end identifies the device and location to read from and
|
||||
attaches pages for the data to be copied to (typically via DMA from
|
||||
the device). The backend acknowledges completed read requests as
|
||||
they finish.
|
||||
|
||||
\item [{\small {\tt WRITE}}:] Write data to the specified block device. This
|
||||
functions essentially as {\small {\tt READ}}, except that the data moves to
|
||||
the device instead of from it.
|
||||
\end{description}
|
||||
|
||||
% um... some old text
|
||||
%% In overview, the same style of descriptor-ring that is used for
|
||||
%% network packets is used here. Each domain has one ring that carries
|
||||
%% operation requests to the hypervisor and carries the results back
|
||||
%% again.
|
||||
|
||||
%% Rather than copying data, the backend simply maps the domain's buffers
|
||||
%% in order to enable direct DMA to them. The act of mapping the buffers
|
||||
%% also increases the reference counts of the underlying pages, so that
|
||||
%% the unprivileged domain cannot try to return them to the hypervisor,
|
||||
%% install them as page tables, or any other unsafe behaviour.
|
||||
%% %block API here
|
||||
|
||||
|
||||
% akw: demoting this to a section -- not sure if there is any point
|
||||
% though, maybe just remove it.
|
||||
\section{Privileged operations}
|
||||
{\it Domain0} is responsible for building all other domains on the server
|
||||
and providing control interfaces for managing scheduling, networking, and
|
||||
blocks.
|
||||
|
||||