The last users of zlib for stubdoms have been removed.
Remove zlib from the stubdom build system, too.
Signed-off-by: Juergen Gross <jgross@suse.com>
Acked-by: Samuel Thibault <samuel.thibault@ens-lyon.org>
There is no user of libpci left in stubdoms.
Remove libpci from the stubdom build system.
Signed-off-by: Juergen Gross <jgross@suse.com>
Acked-by: Samuel Thibault <samuel.thibault@ens-lyon.org>
The Mini-OS based grub-pv is not being built by default since Xen 4.16.
Additionally it can be replaced in most cases by the more modern pvgrub
(part of grub upstream), while grub-pv is based on legacy grub 0.97.
In case someone is really depending on grub-pv, an old build from a
previous Xen version can be used without any problem, as only stable
hypercall interfaces are used by it.
Remove grub-pv from the build system.
Signed-off-by: Juergen Gross <jgross@suse.com>
Acked-by: Samuel Thibault <samuel.thibault@ens-lyon.org>
Acked-by: Jan Beulich <jbeulich@suse.com>
C-stubdom was meant as a base for building new Mini-OS based stubdoms.
It hasn't seen any work for many years now and creating new stubdoms
should use UNIKRAFT instead of Mini-OS.
So remove c-stubdom.
Signed-off-by: Juergen Gross <jgross@suse.com>
Acked-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Teddy Astie <teddy.astie@vates.tech>
In order to build caml-stubdom, it must be explicitly enabled via
"configure --enable-caml-stubdom". The build process is failing due to
stubdom/ocaml.patch failing to apply. Since the patched file has been
modified in 2014 the last time, it seems nobody cares for caml-stubdom
since at least then.
Remove caml-stubdom from the build system.
Signed-off-by: Juergen Gross <jgross@suse.com>
Acked-by: Christian Lindig <christian.lindig@cloud.com>
Acked-by: Henry Wang <Henry.Wang@arm.com>
Acked-by: Andrew Cooper <andrew.cooper3@citrix.com>
Obtaining code over an insecure transport is a terrible idea for
blatently obvious reasons. Even for non-executable data, insecure
transports are considered deprecated.
This patch enforces the use of secure transports in the build system.
Some URLs returned 301 or 302 redirects, so I replaced them with the
URLs that were redirected to.
Signed-off-by: Demi Marie Obenour <demi@invisiblethingslab.com>
Acked-by: Andrew Cooper <andrew.cooper3@citrix.com>
The upstream URLs for zlib, PolarSSL, and the TPM emulator do not work
anymore, so do not attempt to use them.
Signed-off-by: Demi Marie Obenour <demi@invisiblethingslab.com>
Acked-by: Andrew Cooper <andrew.cooper3@citrix.com>
Using qemu-traditional as device model is deprecated for some time now.
So change the default for building it to "disable". This will affect
ioemu-stubdom, too, as there is a direct dependency between the two.
Today it is possible to use a PVH/HVM Linux-based stubdom as device
model. Additionally using ioemu-stubdom isn't really helping for
security, as it requires to run a very old and potentially buggy qemu
version in a PV domain. This is adding probably more security problems
than it is removing by using a stubdom.
Signed-off-by: Juergen Gross <jgross@suse.com>
Reviewed-by: Samuel Thibault <samuel.thibault@ens-lyon.org>
Acked-by: Ian Jackson <iwj@xenproject.org>
Release-acked-by: Ian Jackson <iwj@xenproject.org>
Using qemu-traditional as device model is deprecated for some time now.
So change the default for building it to "disable". This will affect
ioemu-stubdom, too, as there is a direct dependency between the two.
Today it is possible to use a PVH/HVM Linux-based stubdom as device
model. Additionally using ioemu-stubdom isn't really helping for
security, as it requires to run a very old and potentially buggy qemu
version in a PV domain. This is adding probably more security problems
than it is removing by using a stubdom.
Signed-off-by: Juergen Gross <jgross@suse.com>
Reviewed-by: Samuel Thibault <samuel.thibault@ens-lyon.org>
Acked-by: Ian Jackson <iwj@xenproject.org>
Release-Acked-by: Ian Jackson <iwj@xenproject.org>
The stubdom based pv-grub is using a very outdated version of grub
(0.97) and should not be used any longer. Mainline grub has support for
PV guests for a long time now, so that should be used as a boot loader
of a PV domain.
So disable building pv-grub per default. In case someone really wants
to continue using it he/she can still use a pv-grub binary from an older
Xen version or manually enable building it via:
configure --enable-pv-grub
[ This was already disabled in osstest by 8dee6e333622
"make-flight: Drop pvgrub (pvgrub1) tests" -iwj ]
Signed-off-by: Juergen Gross <jgross@suse.com>
Reviewed-by: Samuel Thibault <samuel.thibault@ens-lyon.org>
Acked-by: Ian Jackson <iwj@xenproject.org>
Release-Acked-by: Ian Jackson <iwj@xenproject.org>
This seems to have been omitted in many recent commits. The earliest
of which are, according to git-bisect:
154137dfdb stubdom/configure stubdom: add xenstore pvh stubdom
cc83ee4c6c all configure scripts NetBSD: Fix lock directory path
but it seems that this is true of several later commits too.
Release status: I consider this discrepancy a release critical bug.
Signed-off-by: Ian Jackson <iwj@xenproject.org>
Release-acked-by: Ian Jackson <iwj@xenproject.org>
Add a PVH xenstore stubdom in order to support a Xenstore stubdom on
a hypervisor built without PV-support.
Signed-off-by: Juergen Gross <jgross@suse.com>
Reviewed-by: Samuel Thibault <samuel.thibault@ens-lyon.org>
Acked-by: Wei Liu <wl@xen.org>
These files are in tree so that people can build (including from git)
without needing recent autotools.
We should update them periodically. Debian buster has been Debian
stable fopr a while. Our CI is running buster.
There should be no significant functional change; it's possible that
there are bugfixes to the configure scripts but I have not reviewed
them.
These files were last changed in
83c845033d
libxl: use vchan for QMP access with Linux stubdomain
where a new feature was added. However, that commit contains a lot of
extraneous noise in configure compared to its parent.
Compared to 83c845033dc8bb3a35ae245effb7832b6823174a~, this commit
restores those extraneous changes, leaving precisely the correct
changes. So one way of looking at the changes we are making now, is
that we are undoing accidental changes to the autoconf output.
I used Debian's autoconf 2.69-11 on amd64.
CC: Wei Liu <wl@xen.org>
CC: Nick Rosbrook <rosbrookn@gmail.com>
Reported-by: Nick Rosbrook <rosbrookn@gmail.com>
CC: Paul Durrant <paul@xen.org>
Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
Reviewed-by: Anthony PERARD <anthony.perard@citrix.com>
Release-acked-by: Paul Durrant <paul@xen.org>
Access to QMP of QEMU in Linux stubdomain is possible over vchan
connection. Handle the actual vchan connection in a separate process
(vchan-socket-proxy). This simplified integration with QMP (already
quite complex), but also allows preliminary filtering of (potentially
malicious) QMP input.
Since only one client can be connected to vchan server at the same time
and it is not enforced by the libxenvchan itself, additional client-side
locking is needed. It is implicitly implemented by vchan-socket-proxy,
as it handle only one connection at a time. Note that qemu supports only
one simultaneous client on a control socket anyway (but in UNIX socket
case, it enforce it server-side), so it doesn't add any extra
limitation.
libxl qmp client code already has locking to handle concurrent access
attempts to the same qemu qmp interface.
Signed-off-by: Marek Marczykowski-Górecki <marmarek@invisiblethingslab.com>
Squash in changes of regenerated autotools files.
Kill the vchan-socket-proxy so we don't leak the daemonized processes.
libxl__stubdomain_is_linux_running() works against the guest_domid, but
the xenstore path is beneath the stubdomain. This leads to the use of
libxl_is_stubdom in addition to libxl__stubdomain_is_linux_running() so
that the stubdomain calls kill for the qmp-proxy.
Also call libxl__qmp_cleanup() to remove the unix sockets used by
vchan-socket-proxy. vchan-socket-proxy only creates qmp-libxl-$domid,
and libxl__qmp_cleanup removes that as well as qmp-libxenstat-$domid.
However, it tolerates ENOENT, and a stray qmp-libxenstat-$domid should
not exist.
Signed-off-by: Jason Andryuk <jandryuk@gmail.com>
Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
Change the url scheme to https. This is all in-tree references to
xenbits and the main website except for those in Config.mk.
We leave Config.mk alone for now because those urls are used by CI
systems and we need to check that nothing breaks when we change the
download method.
Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
Reviewed-by: Julien Grall <jgrall@amazon.com>
It is common that build hosts are isolated from outside world. They
don't necessarily have wget or ftp installed.
Turn the error into warning in configure. And point FETCHER to `false'
command if neither wget nor ftp is available, so any attempt to
download will result in error.
Signed-off-by: Wei Liu <wei.liu2@citrix.com>
Acked-by: Andrew Cooper <andrew.cooper3@citrix.com>
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>
Config.mk
MINIOS_UPSTREAM_REVISION } changed from tag to equivalent
QEMU_TRADITIONAL_REVISION } specific commit hash
QEMU_UPSTREAM_REVISION now tracking master again
README, xen/Makefile
Update version number
*/configure
Reran autoconf; only change is version number
tools/Rules.mk, xen/Kconfig.debug
Enable debug.
Reverts 229ff3125b "Use non-debug build for Xen 4.9".
Signed-off-by: Ian Jackson <Ian.Jackson@eu.citrix.com>
In 936a7a54 ("Open Xen 4.8-unstable), output of autogen.sh was not
included. The configure scripts still referred to 4.7.
Run autogen.sh and commit the result.
Signed-off-by: Wei Liu <wei.liu2@citrix.com>
Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
315a8722b4 bumped the version after 4.6
branched. This picks up that change into the generated files.
Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Various configure scripts have the Xen version built into them by
autoconf. Rereun autogen.sh (on Debian wheezy) so that they all say
4.6. There are no changes other than to doc comments, usage messages,
and so forth.
Signed-off-by: Ian Jackson <Ian.Jackson@eu.citrix.com>
This is the version from Debian Wheezy which is what both Ian Jackson and
myself run on our workstations. As committers it is useful to minimise
regeneration noise.
This is purely a run of autogen.sh. I have not tried to build the result.
Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Tested-by: Ian Jackson <ian.jackson@citrix.com>
Now that we have upstream qemu people may want to avoid building this extra
code.
There is a little bit of trickery in stubdom/configure.ac to ensure that the
ioemu stubdom is only built if qemu-traditional is enabled.
libxl will return an error if a caller tries to build a domain using
qemu-xen-traditional when this support was disabled at build time. Since
qemu-xen-traditional has been historically tightly bound to the Xen releases I
don't see any value in supporting "3rd party" provision of
qemu-xen-traditional.
We also do not want/need this on ARM therefore default is on for x86 and off
otherwise.
Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
[ ijc -- trivial conflicts in Tools.mk.in and tools/configure.ac.
Reran autogen.sh ]
Use FETCHER for stubdom, too. This makes stubdom buildsystem
more consistent with tools buildsystem.
Fixes toplevel configure failure if wget is not found
independent if we are going to build stubdom or not.
Signed-off-by: Christoph Egger <chegger@amazon.de>
Reviewed-by: Matt Wilson <msw@amazon.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
Now that the hotplug scripts have been fixed to remove hardcoded paths lets
try this again. From 26470:acaf29203cf9:
This is the defacto (or FHS mandated?) standard location for software
built from source, in order to avoid clashing with packaged software
which is installed under /usr/bin etc.
I think there is benefit in having Xen's install behave more like the
majority of other OSS software out there.
The major downside here is in the transition from 4.2 to 4.3 where
people who have built from source will innevitably discover breakage
because 4.3 no longer overwrites stuff in /usr like it used to so they
pickup old stale bits from /usr instead of new stuff from /usr/local.
Packages will use ./configure --prefix=/usr or whatever helper macro
their package manager gives them. I have confirmed that doing this
results in the same list of installed files as before this patch was
applied.
The hypervisor remains in /boot/ and there is no intention to move it.
Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Acked-by: Roger Pau Monné <roger.pau@citrix.com>
26470:acaf29203cf9 missed a bunch of hardcoded paths, e.g. in the
initscripts. I think at this juncture it is appropriate to revert
this change and try again after some more testing.
Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Acked-by: Roger Pau Monné <roger.pau@citrix.com>
Committed-by: Ian Campbell <ian.campbell@citrix.com>
This is the defacto (or FHS mandated?) standard location for software
built from source, in order to avoid clashing with packaged software
which is installed under /usr/bin etc.
I think there is benefit in having Xen's install behave more like the
majority of other OSS software out there.
The major downside here is in the transition from 4.2 to 4.3 where
people who have built from source will innevitably discover breakage
because 4.3 no longer overwrites stuff in /usr like it used to so they
pickup old stale bits from /usr instead of new stuff from /usr/local.
Packages will use ./configure --prefix=/usr or whatever helper macro
their package manager gives them. I have confirmed that doing this
results in the same list of installed files as before this patch was
applied.
The hypervisor remains in /boot/ and there is no intention to move it.
Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Acked-by: Roger Pau Monné <roger.pau@citrix.com>
Acked-by: Matt Wilson <msw@amazon.com>
Committed-by: Ian Campbell <ian.campbell@citrix.com>
I forgot to do this while checking in 26424:e1d7053e4d45. Refresh now
so as to not cause confusing looking changes next time it is run.
Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Committed-by: Ian Campbell <ian.campbell@citrix.com>
Juergen Gross