9pfs support has been a documented feature since Xen 4.9, but QEMU will
not be built with backend support unless VirtFS is enabled, which is
predicated on the libcap and libattr dev packages being installed. This is
not obvious to anyone intending to use 9pfs.
This patch adds an 'enable-9pfs' option to configure which, if specified,
will cause '--enable-virtfs' to be passed to QEMU's configure. This will
cause the dependency on libcap and libattr to be called out if the packages
are not in installed.
For completeness, specifying 'disable-9pfs' will cause '--disable-virtfs' to
be passed to QEMU's confgure and not specifying an option will keep the
previous behaviour of predicating VirtFS on whether the libcap and libattr
packages are installed.
Signed-off-by: Paul Durrant <paul.durrant@citrix.com>
Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>
Acked-by: Wei Liu <wei.liu2@citrix.com>
It appears that the test in 01d631028 for ipxe's dependency on rombios
is not good enough. Configuring with --disable-rombios doesn't disable
ipxe.
Fix it by testing the dependency after AC_ARG_ENABLE and AC_ARG_WITH
have taken effect.
At the same time, regularise options for ipxe:
--enable-ipxe enable building in-tree ipxe
--disable-ipxe disable building in-tree ipxe
--with-system-ipxe specify a path to be baked into code, disable
building in-tree ipxe, this trumps --{en,dis}able-ipxe
--without-system-ipxe error
Signed-off-by: Wei Liu <wei.liu2@citrix.com>
Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
The paths shouldn't be set to "yes". We ask the user to set absolute
paths because Xen's build system doesn't know where to search, and the
build machine doesn't necessarily have those binaries present in the
first place.
Reported-by: Anthony Perard <anthony.perard@citrix.com>
Signed-off-by: Wei Liu <wei.liu2@citrix.com>
Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
This option lets user specify which binary is to be used as ipxe. If
it is specified, the in-tree ipxe will not be built. This option is in
line with other --with-system-* options we provide.
Signed-off-by: Wei Liu <wei.liu2@citrix.com>
Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
Curl and xml2 are not required anymore since 185bb58be3 ("tools: drop
libxen") removed their only user.
Signed-off-by: Olaf Hering <olaf@aepfle.de>
Acked-by: Wei Liu <wei.liu2@citrix.com>
[ wei: run autogen.sh ]
The ocaml safe-strings patch uses code introduced in ocaml 4.02
so update the minimal version.
Signed-off-by: Michael Young <m.a.young@durham.ac.uk>
Acked-by: Christian Lindig <christian.lindig@citrix.com>
If ocaml.m4 didn't find ocamlopt, disable all the ocaml builds.
Currently our Makefiles do not work properly when the native code
compiler (`ocamlopt') is not available. In principle this should be
fixed to fall back to bytecode, but this is not a task for this stage
of the Xen 4.9 release.
Without this change, we cannot build on systems with only ocamlc.
That includes Debian jessie ARM64, as used on the new ARM64 hardware
in the Xen Project CI test lab.
When the Makefiles are fixed, this commit should be reverted.
Committers: Please rerun autogen.sh.
CC: Julien Grall <julien.grall@arm.com>
CC: Christian Lindig <christian.lindig@citrix.com>
CC: Jonathan Ludlam <Jonathan.Ludlam@citrix.com>
CC: David Scott <dave@recoil.org>
CC: Wei Liu <wei.liu2@citrix.com>
Tested-by: Ian Jackson <Ian.Jackson@eu.citrix.com>
Signed-off-by: Ian Jackson <Ian.Jackson@eu.citrix.com>
Acked-by: Wei Liu <wei.liu2@citrix.com>
Instead of generating the *.pc.in files at configure time use the new
pkg-config scheme for those files. Add the dependencies to other Xen
libraries as needed.
Signed-off-by: Juergen Gross <jgross@suse.com>
Acked-by: Wei Liu <wei.liu2@citrix.com>
This seems to be looking for a function MD5. But nothing uses it.
The build works fine if this is disabled and libcrypto is not
installed.
This check was first introduced in 68a3e1e873 "[TOOLS] Add more
checks for devel packages." in 2006. At that time -lcrypto was used
by tools/blktap/ and tools/vtpm_manager/, which are both gone now.
Signed-off-by: Ian Jackson <ian.jackson@citrix.com>
Acked-by: Wei Liu <wei.liu2@citrix.com>
Release-acked-by: Wei Liu <wei.liu2@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>
It uses static DSDT table like the way x86 uses. Currently the DSDT
table only contains processor device objects and it generates the
maximal objects which so far is 128.
While the GUEST_MAX_VCPUS is defined under __XEN__ or __XEN_TOOLS__, it
needs to add -D__XEN_TOOLS__ to compile mk_dsdt.c.
Also only check iasl for aarch64 in configure since ACPI on ARM32 is not
supported.
Signed-off-by: Shannon Zhao <shannon.zhao@linaro.org>
Acked-by: Julien Grall <julien.grall@arm.com>
Acked-by: Wei Liu <wei.liu2@citrix.com>
[ wei: run autogen.sh and fix compilation on x86 ]
Signed-off-by: Wei Liu <wei.liu2@citrix.com>
Currently configure code doesn't define {SEABIOS/OVMF}_PATH when
--with-system-{ovmf/seabios} is used. Fix this by making sure those
defines are always set if the internal {ovmf/seabios}_path variables are
also set.
Signed-off-by: Roger Pau Monné <roger.pau@citrix.com>
Suggested-by: Wei Liu <wei.liu2@citrix.com>
Cc: Wei Liu <wei.liu2@citrix.com>
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
[ wei: run autogen.sh ]
Acked-by: Wei Liu <wei.liu2@citrix.com>
Blktap2 is effectively dead code for a few years.
Notable changes in this patch:
0. Unhook blktap2 from build system
1. Now libxl no longer supports TAP disk backend, appropriate assertions
are added and some code paths now return ERROR_FAIL
2. Tap is no longer a supported backend in doc
3. Remove relevant entries in MAINTAINERS
A patch to actually remove blktap2 directory will come later.
Signed-off-by: Wei Liu <wei.liu2@citrix.com>
Acked-by: George Dunlap <George.Dunlap@eu.citrix.com>
Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
... to compile SeaBIOS and OVMF. Only depend on CONFIG_*.
If --with-system-* configure option is used, then set *_CONFIG=n to not
compile SEABIOS and OVMF.
Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
Reviewed-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Acked-by: Wei Liu <wei.liu2@citrix.com>
Those paths are to be used by libxl, in order to load the firmware in
memory. If a system path is not defined via --with-system-seabios or
--with-system-ovmf, then default to the Xen firmware directory.
Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
Reviewed-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Acked-by: Wei Liu <wei.liu2@citrix.com>
In order to prepare starting a xenstore domain split out the starting
of the xenstore daemon from the xencommons script into a dedicated
launch-xenstore script.
A rerun of autogen.sh is required.
Signed-off-by: Juergen Gross <jgross@suse.com>
Acked-by: Wei Liu <wei.liu2@citrix.com>
On a system with systemd the xenstore sockets are created via systemd.
Remove the related configuration files in order to be able to decide
at runtime whether the sockets should be created or not. This will
enable Xen to start xenstore either via a daemon or via a stub domain.
As the xenstore domain start program will exit after it has done its
job prepare the same behaviour to be tolerated by systemd for the
xenstore daemon by specifying the appropriate flags in the service
file.
A rerun of autogen.sh is required.
Signed-off-by: Juergen Gross <jgross@suse.com>
Acked-by: Wei Liu <wei.liu2@citrix.com>
Acked-by: David Scott <dave@recoil.org>
A dedicated Xen driver domain init service starts "xl devd" in domU. But
currently, it is only supplied in the form of a SysV init script, which
systemd users run through a backward compatiblity wrapper automatically
generated by systemd-sysv-generator. This patch adds a (naturally more
lightweight) native systemd unit to be used instead.
The xendriverdomain service is only relevant to domU, but should not run
in dom0. Therefore, the systemd unit uses "ConditionVirtualization=xen",
which evaluates to true in domU and (since systemd version 214, released
on 2014-06-11) to false in dom0. Users or distributors who need to be
compatible with even older systemd versions, but still want to prevent
"xl devd" startup in dom0, could add the following line in [Service]:
ExecStartPre=/bin/sh -c "! grep -q control_d /proc/xen/capabilities"
(Please rerun autogen.sh after applying this patch)
Signed-off-by: Rusty Bird <rustybird@openmailbox.org>
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Cc: Wei Liu <wei.liu2@citrix.com>
Acked-by: Wei Liu <wei.liu2@citrix.com>
[ wei: rerun autogen.sh ]
Generate oxenstored.conf with configure. This involves modifying
tools/configure.ac and rerun autogen.sh.
Signed-off-by: Wei Liu <wei.liu2@citrix.com>
Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
COLO and Remus net buffer support both depend on the availability of
libnl. Use a generic name.
No functional changes.
Signed-off-by: Wei Liu <wei.liu2@citrix.com>
Acked-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>
Changeset 1166ecf ('tools/Rules.mk: Don't optimize debug builds; add
macro debugging information') exposed a bug whereby the autoconf stuff
in tools was setting its own debug value (defaulting to ENABLED, even
for releases) instead of honoring the value set in Config.mk.
After that changeset, if the global build has -D_FORTIFY_SOURCE
enabled (as is the default in CentOS 7 rpmbuild), then the tools build
will fail (because debug builds default to on).
There should be only one place to specify whether to build debug or
not, and Config.mk is already included by the relevant makefiles. So
simply remove the tools/configure debug option and everything falls
into place naturally.
Signed-off-by: George Dunlap <george.dunlap@eu.citrix.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
Acked-by: Wei Liu <wei.liu2@citrix.com>
Per http://wiki.qemu.org/ChangeLog/1.0 and the fact that no currently
supported distro ships the x86 system emulator binary as 'qemu', this
changes the default when a user specifies --with-system-qemu without a
PATH to 'qemu-system-i386', otherwise the default results in a
non-functional setup.
[ Reran autogen.sh -iwj ]
Signed-off-by: Doug Goldstein <cardoe@cardoe.com>
Acked-by: Wei Liu <wei.liu2@citrix.com>
When --with-system-qemu is used, it is possible that we cannot find
qemu-system-i386 in LIBEXEC_BIN, which can cause error in xencommons
init script and xen-qemu-dom0-disk-backend.service systemd service.
Signed-off-by: Ting-Wei Lan <lantw44@gmail.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
The removal of the udev rules highlighted that although it has been
replaced by "xl devd" there isn't an initscript to replace it.
To enable this add a --pidfile option to xl devd.
Tested on Linux by running the script in dom0 and checking the daemon
was started/stopped, but not in an actual driver domain environment
since I don't have one conveniently available. I also checked that
running without the --pidfile option still works.
Scripts mainly cribbed from the xencommons for each platform.
Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Cc: Roger Pau Monné <roger.pau@citrix.com>
Cc: Konrad Rzeszutek Wilk <konrad@darnok.org>
Cc: George Dunlap <george.dunlap@eu.citrix.com>
Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
Acked-by: Wei Liu <wei.liu2@citrix.com>
They are no longer needed, having been replaced by a daemon for
driverdomains which will run scripts as necessary.
Worse yet, they seem to be broken for script-based block devices, such
as block-iscsi. This wouldn't matter so much if they were never run
by default; but if you run block-attach without having created a
domain, then the appropriate node to disable running udev scripts will
not have been written yet, and the attach will silently fail.
Rather than try to sort out that issue, just remove them entirely.
Signed-off-by: George Dunlap <george.dunlap@eu.citrix.com>
Acked-by: Wei Liu <wei.liu2@citrix.com>
When the property "clock-frequency" is present in the DT timer node, it
means that the bootloader/firmware didn't correctly configure the
CNTFRQ/CNTFRQ_EL0 on each processor.
The best solution would be to fix the offending firmware/bootloader,
although it may not always be possible to modify and re-flash it.
As it's not possible to trap the register CNTFRQ/CNTFRQ_EL0, we have
to extend xen_arch_domainconfig to provide the timer frequency to the
toolstack when the property "clock-frequency" is present to the host DT
timer node. Then, a property "clock-frequency" will be created in the guest
DT timer node if the value is not 0.
We could have set the property in the guest DT no matter if the property
is present in the host DT. Although, we still want to let the guest
using CNTFRQ in normal case. After all, the property "clock-frequency"
is just a workaround for buggy firmware.
Also add a stub for fdt_property_u32 which is not present in libfdt <
1.4.0 used by distribution such as Debian Wheezy.
Signed-off-by: Julien Grall <julien.grall@citrix.com>
Tested-by: Chris Brand <chris.brand@broadcom.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
[ ijc -- ran autogen.sh ]
binutils 2.22 changed ld default from --copy-dt-needed-entries
to -no-copy-dt-needed-entries. This revealed that some objects
are linked implicitly with libtinfo and newer ld fails to build
relevant executables.
Below is short explanation why we should not do that...
http://fedoraproject.org/wiki/UnderstandingDSOLinkChange says:
The default behaviour for ld (my note: before version 2.22) allows
users to 'indirectly' link to required objects/libraries through
intermediate objects/libraries. While this is convenient, it can
also be dangerous because it makes your program's dependencies tied
to the dependencies of other objects. If those objects ever change
their linkages, they can break your program without any changes
to your own code!
Signed-off-by: Daniel Kiper <daniel.kiper@oracle.com>
Acked-by: Wei Liu <wei.liu2@citrix.com>
We are going to need this to generate the userspace flask.h header.
Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Acked-by: Wei Liu <wei.liu2@citrix.com>
[ ijc -- ran autogen.sh ]
There was a missing [ in the aio check which lead to never check if aio
is present on the platform.
Signed-off-by: Julien Grall <julien.grall@citrix.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
[ ijc -- ran autogen.sh ]
Allow the user to pass additional nodes to the guest device tree. For
this purpose, everything in the node /passthrough from the partial
device tree will be copied into the guest device tree.
The node /aliases will be also copied to allow the user to define
aliases which can be used by the guest kernel.
A simple partial device tree will look like:
/dts-v1/;
/ {
#address-cells = <2>;
#size-cells = <2>;
passthrough {
compatible = "simple-bus";
ranges;
#address-cells = <2>;
#size-cells = <2>;
/* List of your nodes */
}
};
Note that:
* The interrupt-parent property will be added by the toolstack in
the root node
* The properties compatible, ranges, #address-cells and #size-cells
in /passthrough are mandatory.
The helpers provided by the libfdt don't perform all the necessary
security check on a given device tree. Therefore, only trusted device
tree should be used.
Note: The partial device tree code requires the presence of libfdt
functions which have been only correctly exported in libfdt 1.4.0 and
higher. All the major distributions but Debian Wheezy are using v1.4.0
or higher. It has been decided to disable partial device tree support on
OSes where libfdt doesn't meet the requirement.
Signed-off-by: Julien Grall <julien.grall@linaro.org>
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Cc: Wei Liu <wei.liu2@citrix.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
[ ijc -- ran autogen.sh ]
The functions fdt_{first,next}_subnode may not be available because:
* It has been introduced in 2013 => Doesn't work on Wheezy
* The prototype exists but the functions are not exposed. Don't ask
why...
The later has been fixed recently in the dtc repo [1]
When the functions are not available, implement our own in order to use
them in a following patch.
Note that the _hidden attribute is placed in both the prototype and the
declaration because some version of libfdt expose the prototype but not
the declaration.
[1] git://git.kernel.org/pub/scm/utils/dtc/dtc.git
commit a4b093f7366fdb429ca1781144d3985fa50d0fbb
Signed-off-by: Julien Grall <julien.grall@linaro.org>
Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
Cc: Wei Liu <wei.liu2@citrix.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
[ ijc -- ran autogen.sh ]
Avoid late build failure in openSUSE 11.4, it has just pixman-0.20:
....
[ 211s] ERROR: pixman >= 0.21.8 not present. Your options:
[ 211s] (1) Preferred: Install the pixman devel package (any recent
[ 211s] distro should have packages as Xorg needs pixman too).
[ 211s] (2) Fetch the pixman submodule, using:
[ 211s] git submodule update --init pixman
....
Signed-off-by: Olaf Hering <olaf@aepfle.de>
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Cc: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Cc: Ian Campbell <ian.campbell@citrix.com>
Cc: Wei Liu <wei.liu2@citrix.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
Some systems have python-config include -D_FORTIFY_SOURCE in the
CFLAGS. But -D_FORTIFY_SOURCE does not (currently) work with -O0, and
-O0 is enabled in debug builds (since 1166ecf781). As a result, on
those systems, debug builds fail.
Work around this problem as follows:
* In configure, detect -D_FORTIFY_SOURCE in $(python-config --cflags)
* If detected, set the new autoconf substitution and make variable
PY_NOOPT_CFLAGS to -O1.
* In tools/Rules.mk, where we add -O0, also add PY_NOOPT_CFLAGS
(which will override the -O0 with -O1 if required).
Overriding the -O0 is better than disabling Fortify because the
latter might have an adverse security impact. A user who wants to
disable optimisation completely even for Python and also disable
Fortify can set the environment variable
EXTRA_CFLAGS_XEN_TOOLS='-U_FORTIFY_SOURCE -O0'
Signed-off-by: Ian Jackson <Ian.Jackson@eu.citrix.com>
Reported-by: Jan Beulich <JBeulich@suse.com>
Signed-off-by: Jan Beulich <jbeulich@suse.com>
CC: Jan Beulich <JBeulich@suse.com>
CC: Ian Campbell <Ian.Campbell@citrix.com>
CC: Euan Harris <euan.harris@citrix.com>
CC: Wei Liu <wei.liu2@citrix.com>
CC: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Tested-by: Don Slutz <dslutz@verizon.com>
QEMU upstream requires the use of pixman. When pixman is not present the
system, the configure of QEMU will fail with:
ERROR: pixman not present. Your options:
(1) Preferred: Install the pixman devel package (any recent
distro should have packages as Xorg needs pixman too).
(2) Fetch the pixman submodule, using:
git submodule update --init pixman
I think we can use by default the version on the system. So check it
a Xen configuration time to avoid a build issue later.
Signed-off-by: Julien Grall <julien.grall@linaro.org>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
[ ijc -- reran autogen.sh, adjusted comment ]
A pkg-config file for libxl. It also contains two variables
(xenfirmwaredir and libexec_bin) so that tools that are very keen on
knowing the locations of Xen binaries (say, libvirt) can use them to
determine the location of the binaries.
Signed-off-by: Wei Liu <wei.liu2@citrix.com>
Cc: Ian Campbell <ian.campbell@citrix.com>
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
[ ijc -- ran autogen.sh ]
This was disabled by default in Xen 4.4. Since xend has now been
removed from the tree I don't believe anything is using it.
We need to pass an explicit CONFIG_BLKTAP1=n to qemu-xen-traditional
otherwise it defaults to y and doesn't build.
This patch does all the ground work, the tools/blktap directory will
be removed in the next (*huge*) patch.
Note that this has no impact on blktap2, which is what libxl supports.
blktap1 was only usable via xend which has already been removed.
Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Acked-by: Wei Liu <wei.liu2@citrix.com>
Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>