* Change version number in README and xen/Makefile to `4.8-unstable'.
* Set `debug ?= y' in Config.mk.
* Set QEMU_UPSTREAM_REVISION to track qemu-xen.git `master'.
* Set MINIOS_UPSTREAM_REVISION and QEMU_TRADITIONAL_REVISION back to
commit hashes, rather than 4.8 tags.
Hypervisor debug enablement is left aside for now.
Signed-off-by: Ian Jackson <Ian.Jackson@eu.citrix.com>
We upgraded ipxe in 38ab99b2 ("ipxe: update to new commit"). That
version of ipxe requires liblzma to build.
Check that in configure and document this in README.
Signed-off-by: Wei Liu <wei.liu2@citrix.com>
Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
* Change QEMU_UPSTREAM_REVISION MINIOS_UPSTREAM_REVISION and
QEMU_TRADITIONAL_REVISION to refer to the Xen 4.8.0-rc1 tags.
* Change README and xen/Makefile to refer to Xen 4.8.0-rc (note, the
RC number is not included, so we do not have to update these again).
I reran autogen.sh as per the release checklist and this produced no
changes, as expected. (Debian jessie i386.)
Signed-off-by: Ian Jackson <Ian.Jackson@eu.citrix.com>
Acked-by: Wei Liu <wei.liu2@citrix.com>
* Change version number in README and xen/Makefile to `4.8-unstable'.
* Set `debug ?= y'.
* Set QEMU_UPSTREAM_REVISION to track qemu-xen.git `master'.
Signed-off-by: Ian Jackson <Ian.Jackson@eu.citrix.com>
CC: Wei Liu <wei.liu2@citrix.com>
* Update README and xen/Makefile to "Xen 4.7-rc"
* Fix QEMU_UPSTREAM_REVISION to a tag, so we get a specific commit
Signed-off-by: Ian Jackson <Ian.Jackson@eu.citrix.com>
bcc/ld86/as86 are necessary when we build ROMBIOS. However if we do not
build it (and are not building qemu-trad), the build requirements are
overly strict and can lead to failures.
Signed-off-by: Doug Goldstein <cardoe@cardoe.com>
Reviewed-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Xen now builds on x86 with Clang 3.5 and 3.8. Update README to reflect this.
Mark Clang as no longer a permitted failure in Travis, to prevent future
regressions slipping back in.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Doug Goldstein <cardoe@cardoe.com>
When building on 64-bit platforms this prevents build errors for
32-bit components which are enabled on a default build.
Signed-off-by: Sander Eikelenboom <linux@eikelenboom.it>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
* Change README to say `Xen 4.6-rc'
* Change XEN_EXTRAVERSION so that we are `4.6.0-rc'
Note that the RC number (eg, 1 for rc1) is not in the version string,
so that we do not need to update this again when we cut the next RC.
Signed-off-by: Ian Jackson <Ian.Jackson@eu.citrix.com>
Acked-by: Wei Liu <wei.liu2@citrix.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
CC: Jan Beulich <jbeulich@suse.com>
CC: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
* Update README's figlet.
* Remove obsolete 4.3 features paragraph from README (!)
* Update QEMU_UPSTREAM_REVISION to refer simply to `master'
* Update QEMU_TRADITIONAL_REVISION to refer to the actual commit hash.
* Change version in xen/Makefile to 4.6.0-unstable
Signed-off-by: Ian Jackson <Ian.Jackson@eu.citrix.com>
Document how to use configure and what to pass to make(1).
Signed-off-by: Olaf Hering <olaf@aepfle.de>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
[ ijc -- fix a few typos ]
This replaces config/Linux.modules with a configure option. As a result
of this change only a single xencomons.in is required, instead of a
xencomons.in.in and sed hackery.
After this change blktap2 and blktap will be loaded at the same time.
This is already done in out-of-tree xencommons scripts, and systemd will
load both modules as well. No harm is expected by loading both modules.
Signed-off-by: Olaf Hering <olaf@aepfle.de>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
Cc: Ian Campbell <ian.campbell@citrix.com>
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Cc: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Cc: Wei Liu <wei.liu2@citrix.com>
[ ijc -- ran autogen.sh as requested ]
Libnl3 is required for controlling Remus network buffering.
This patch adds dependency on libnl3 (>= 3.2.8) to autoconf scripts.
It also provides the ability to configure tools without libnl3 support
i.e., without network buffering support.
When there is no network buffering support, libxl__netbuffer_enabled()
returns 0, otherwise returns 1. The callers of this api will be
introduced in the rest of the series.
NOTE: This patch changes tools/configure.ac, please rerun
autogen.sh while applying the patch.
Signed-off-by: Shriram Rajagopalan <rshriram@cs.ubc.ca>
Signed-off-by: Lai Jiangshan <laijs@cn.fujitsu.com>
Signed-off-by: Yang Hongyang <yanghy@cn.fujitsu.com>
Reviewed-by: Wen Congyang <wency@cn.fujitsu.com>
Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
Acked-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
This adds the systemd xen service / module files and integrates
support into the build system.
This goes in with AX_AVAILABLE_SYSTEMD() which will enable
systemd if development libraries have been found on your
build system. If you don't have systemd on target systems
for binaries built with systemd then the binary will not
work, you must explicitly disable systemd support if you
do not want to build systemd support.
When systemd libraries are present only systems that
have booted into systemd go through the systemd initialization,
otherwise the SysVinit is used.
These are originally based on the Fedora systemd files.
Changes made from Fedora's systemd files:
* split sockets into two files to claim different permissions
* Use /bin/sh -c exec to for a simple launcher implementation
* enables systemd socket activation for C xenstored and Ocaml
oxenstored
* use sd_notify(), so change the service to Type=notify, because of
this we remove the PIDFile specification as we don't care for it, and let
systemd do its magic for us, this also means we don't have to fork
so we use --no-fork with systemd
* defines a modules-load.d, its original source file will be shared
between systemd and old init systems
* simplify service files with ConditionVirtualization=xen which uses
the built in systemd virtualization backend detection, these
service files will not be available to start on systems that do not
boot with xen as a hypervisor
* use autoconf to replace @variable@ paths for us which piggy
backs on top of the latest autoconf changes to xen
* removes oxenstored service file in favor of a system variable which
controls which which xentored to use at run time, we avoid multiple
service files this way.
* simplifies startup to not require polling on the sockets
as initial socket management is handled by systemd, we just
take on the socket later once anything pokes at it, a simple nc -U
(as root) on any of the sockets files can activate the service for example.
Anything queued up will be sent to us once we start. Socket activation
should in theory also let us dynamically switch between xenstores but more
importantly we could upgrade xenstored while keeping all active
socket communication queued up, but in order to take advantage of
this we eventually would need to remove the requirement of not being
able to bring down the xenstored. Even though active sockets are
supported since most libxl communication doesn't triggger a check
on the unix socket first administrators are encouraged to enable
the xenstored.service to triggger an initialization of the xenstored
upon bring up. Some systems also never use unix sockets for
communication with the xenstored and as such active sockets will
not be used there.
* allow for xenstored configuration through *either* of these
configuration files:
- /etc/sysconfig/xenstored
- /etc/default/xenstored
The /etc/default/xenstored will let debian based systems do
the same, while SUSE/OpenSUSE/Fedora/RedHat can keep on chugging
with sysconfig. We leave these files all commented out by default
though given that for systemd we want to encourage not using them.
* ensures we create the run directory as most systems will likely
be using a tmpfs for run dirs for the pid files
* Some systems define the selinux context in the systemd Option for the
/var/lib/xenstored tmpfs:
Options=mode=755,context="system_u:object_r:xenstored_var_lib_t:s0"
For the upstream version we remove that and let systems specify the
context on their system /etc/default/xenstored or /etc/sysconfig/xenstored
$XENSTORED_MOUNT_CTX variable, with a default to none.
* takes advantage of the shared xendomains helper for the xendomains
service
* Add the new dom0 that gets kicked off for disk backend access into
its own systemd service associated to xen
We end up with these systemd files:
General requirements:
* proc-xen.mount
* var-lib-xenstored.mount
xenstored:
* xenstored.service
* xenstored.socket
* xenstored_ro.socket
* xenconsoled.service
* xen-qemu-dom0-disk-backend.service.in
Optional:
* xendomains.service
* xen-watchdog.service
As for integration with xen, we house keep all the systemd files
under a new directory tools/hotplug/Linux/systemd/ and will be targeted
by default when building on Linux systems if systemd development
libraries are present at build time.
The systemd files will be sanitized for meta @VARIABLES@ upon
configuration and installed upon the install target. Systems that
do not use systemd can still get systemd service unit files installed
if the build system enabled systemd support, this however does not
mandate a requirement of having systemd libraries present. Old init
scripts are always installed.
If you don't specify a prefix you will end up with the services
files under /usr/local/lib/systemd/system/ by default, and systemd
modules-load.d conf files under /usr/local/lib/modules-load.d/ which
systemd does look for (although it seems this is not documented).
Distributions are expected to provide their /usr/ prefix to end up in
the more generic location upon distribution install at
/usr/lib/systemd/system/ and /usr/lib/modules-load.d/ respectively.
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Cc: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Cc: Ian Campbell <ian.campbell@citrix.com>
Cc: Jan Rękorajski <baggins@pld-linux.org>
Cc: M A Young <m.a.young@durham.ac.uk>
Cc: Jacek Konieczny <jajcus@jajcus.net>
Cc: xen-devel@lists.xenproject.org
Signed-off-by: Luis R. Rodriguez <mcgrof@suse.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
[ ijc -- ran autogen.sh ]
As it stands oxenstored will be used by default if ocaml tools are
found, the init system will also try to use oxenstored first if its
found otherwise the cxenstored will be used. Lets simplify the init
script and let users be explicit about the preference through configure.
This adds support to let you be explicit about the xenstored preference,
you can only use one of these two options:
./configure --with-xenstored=xenstored
./configure --with-xenstored=oxenstored
We continue with the old behaviour and default oxenstored will be used
but only if you have ocaml dependencies. Since the xenstored preference
is explicit now and since we require configure substitutions for it we
make use of the AX_XEN_EXPAND_CONFIG() helpers as otherwise substitution
for SBINDIR is not propagated from the top level configuration.
All this allows us to simplify the init script to use the configured
xenstore from the start. We update the sysconfig/default xencommons file
with the paths for the different options though, this can be used by
users to override the default xenstored, this follows the old behaviour
but we now just explicitly provide the full configured paths for users.
As before, changing the xenstore requires a reboot.
In order to help with documentation we update the README with some
details on configure usage refer to the wiki [0] [1] [2] for more elaborate
details.
Since we are now parsing an entry within Paths.mk.in on tools we let
the move the parsing of the file to be the tool's configure.
[0] http://wiki.xen.org/wiki/Xenstored
[1] http://wiki.xen.org/wiki/XenStore
[2] http://wiki.xen.org/wiki/XenStoreReference
Cc: Ian Campbell <ian.campbell@citrix.com>
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Cc: Jan Beulich <jbeulich@suse.com>
Cc: Keir Fraser <keir@xen.org>
Cc: Tim Deegan <tim@xen.org>
Signed-off-by: Luis R. Rodriguez <mcgrof@suse.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
[ ijc -- ran autogen.sh ]
This will allow us to share the same module list with
systemd, and lets us upkeep it in one place. Document this
while at it on the top level README and expand on the wiki:
http://wiki.xen.org/wiki/Category:Host_Configuration#Kernel_modules
In order to upkeep parallelism builds be explicit about the
requirement to complete all actions before any installation
targets.
Signed-off-by: Luis R. Rodriguez <mcgrof@suse.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
It is quite inappropriate to keep a hacked up versions of figlet in our source
tree, especially when the purpose of the hackary is just to provide a text to
octal conversion.
This version of figlet contributes a surprisingly large proportion of the
Coverity issues found under xen/ (and therefore attributed against Xen)
Figlet can be found in all distros, so make use of it. We keep xen.flf (being
the Xen figlet font) and replace the hacked up octal transform with a short
python script.
The Xen Makefile has been tweaked in such a way that it still prints the
figlet banner for the build.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Acked-by: Keir Fraser <keir@xen.org>
CC: Jan Beulich <JBeulich@suse.com>
CC: Tim Deegan <tim@xen.org>
Acked-by: Ian Campbell <Ian.Campbell@citrix.com>
CC: Ian Jackson <Ian.Jackson@eu.citrix.com>
We have defaulted to using the system libaio for a while now and I din't think
there are any relevant distros which don't have it that running Xen 4.4 would
be reasonable on.
Also it has caused confusion because it is not ever wanted on ARM, but the
build system doesn't express that (could be fixed, but deleting is the right
thing to do anyway).
Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
Acked-by: Matt Wilson <msw@amazon.com>
Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
Updated the figlet version number to "Xen 4.3-rc". Also remove the
paragraph touting the benefits of Xen 4.2. At some point we should
replace it with a paragraph touting the benefits of Xen 4.3.
Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
It is sometimes hard to discover all the optional tools that should be
on a system to build all available Xen documentation. By checking for
documentation generation tools at ./configure time and displaying a
warning, Xen packagers will more easily learn about new optional build
dependencies, like markdown, when they are introduced.
Based on a patch by Matt Wilson. Changed to use a separate
docs/configure which is called from the top-level in the same manner
as stubdoms.
Rerun autogen.sh and "git add docs/configure" after applying this patch.
Signed-off-by: Matt Wilson <msw@amazon.com>
Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Acked-by: Matt Wilson <msw@amazon.com>
(For the change to introduce docs/configure)
Acked-by: Roger Pau Monné <roger.pau@citrix.com>
Committed-by: Ian Campbell <ian.campbell@citrix.com>
Hotplug has been replaced by udev since several years. Remove the
hotplug related files and install udev unconditionally.
This makes it possible to remove udev from rpm BuildRequires which
reduces the buildtime dependency chain. For openSuSE:Factory it was
done just now:
http://lists.opensuse.org/opensuse-buildservice/2012-10/msg00085.html
The patch by itself will have no practical impact unless someone
attempts to build and run a Xen dom0 on a really old base system. e.g.
circa SLES9/2007 or earlier
Signed-off-by: Olaf Hering <olaf@aepfle.de>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
Committed-by: Ian Campbell <ian.campbell@citrix.com>
Added autotools magic to replace custom check scripts. The previous
checks have been ported to autoconf, and some additional ones have
been added (plus the suggestions from running autoscan). Two files are
created as a result from executing configure script, config/Tools.mk
and config.h.
conf/Tools.mk is included by tools/Rules.mk, and contains most of the
options previously defined in .config, that can now be set passing
parameters or defining environment variables when executing configure
script.
config.h is only used by libxl/xl to detect yajl_version.h.
[ tools/config.sub and config.guess copied from
autotools-dev 20100122.1 from Debian squeeze i386,
which is GPLv2.
tools/configure generated using the included ./autogen.sh
which ran autoconf 2.67-2 from Debian squeeze i386. autoconf
is GPLv3+ but has a special exception for the autoconf output;
this exception applies to us and exempts us from complying
with GPLv3+ for configure, which is good as Xen is GPL2 only.
- Ian Jackson ]
Signed-off-by: Roger Pau Monne <roger.pau@entel.upc.edu>
Tested-by: Ian Jackson <ian.jackson@eu.citrix.com>
Committed-by: Ian Jackson <Ian.Jackson@eu.citrix.com>
Upstream Qemu, just added to the Xen build system, needs GLib 2.0 and
pkg-config to compile.
Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Committed-by: Keir Fraser <keir@xen.org>
although this tool is strictly speaking optional we are providing various user
docs in this format so increase the changes that they will install it.
Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Committed-by: Ian Jackson <ian.jackson.citrix.com>
Acked-by: Ian Jackson <ian.jackson.citrix.com>
I have confirmed that the relevant pages have been transitioned.
What remains is pages which have not yet been moved over:
$ rgrep xenwiki *
tools/libxen/README:http://wiki.xensource.com/xenwiki/XenApi
tools/xenballoon/xenballoond.README:http://wiki.xensource.com/xenwiki/Open_Topics_For_Discussion?action=AttachFile&do=get&target=Memory+Overcommit.pdf
Note that "PythonInXlConfig" never existed in the old wiki and does not exist
in the new. This reference was introduced by 22735:cb94dbe20f97 and was
supposed to have been written prior to the 4.1 release. I have transitioned it
anyway but it's not clear how valuable the message actually is. Perhaps we
should just remove that aspect of it?
Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Committed-by: Ian Jackson <ian.jackson.citrix.com>
Acked-by: Ian Jackson <ian.jackson.citrix.com>
I could have sworn I did this years ago.
IIRC the need for our own copy was due to the use of io_set_eventfd which is
not present in version 0.3.106. However it is in 0.3.107 the first version of
which was uploaded to Debian in June 2008 (I can't find a better reference for
the release date).
The necessary version is available in Debian Lenny onwards and is in at least
RHEL 6, Fedora 13 and OpenSuSE 11.3. The necessary version appears to not be
available in RHEL 5 or SLES 11 which is why I haven't simply nuked the in tree
version.
This is based on tools-system-libaio.diff from the Debian packaging although I
have made it optional (but default on).
Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>
We use the yajl parser, but we need to make a tree from the parse result
to use it outside the parser.
So this patch include json_object struct that is used to hold the JSON
data.
Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
Committed-by: Ian Jackson <ian.jackson.citrix.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
Pyxml/xmlproc is being used in tools/xen/xm/xenapi_create.py but is
unmaintained for several years now. xmlproc is used only for validating
XML documents against a DTD file.
This patch replaces the pyxml/xmlproc based XML validation with code
based on lxml, which is actively maintained.
Signed-off-by: Stephan Peijnik <spe@anexia.at>
Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
committer: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Cloning and building a kernel as part of the Xen distribution
implicitly advises that this kernel is the best kernel for all users
and many users appear to be under this impression, even though there
is no fundamental coupling between the Xen distribution and a
particular domain 0 kernel.
There are several choices available for domain 0 kernel, as well as
other user specific variations in requirements e.g. for kernel
configurations. It's not clear that whatever the xen build system
happens to produce (which is really tailored to the needs of the
automated build system) is best for anybody.
Coupling the kernel build with the Xen build has proved problematic
for stable Xen releases as it implicitly blesses the particular kernel
(at a particular point in time) as a constituent part of the Xen
release, while in reality the OS kernels are separate entities with
their own release cycles which may or may not coincide with the
maintenance of Xen stable branches.
Therefore disable the building of a kernel as part of the Xen
distribution by default and instead direct users to use an OS
distribution provided kernel (properly packaged with security updates
via the normal distribution mechanisms etc) where possible and give
pointers to suitable resources providing guidance for cases where it
is not.
This decouples the implicit advice as to the best kernel at any moment
from Xen's own release cycle and removes the implicit suggestion that
only particular domain 0 kernel will do.
The actual infrastructure is left in place since the automated test
system (currently) relies on it (but always asks for the specific
kernel variant it wants for a particular test).
(I also tried to remove Linux-isms from the README's Quick start
guide. In particular I'm not sure what was supposedly Linux specific
about steps 3 and 4 therefore I have removed the suggestion that they
are.)
Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
Ian Jackson