x86/viridian: Re-purpose the HVM parameter to be a feature mask

The following commits introduced the time reference counter MSR and
TSC/APIC frequency MSRs into the viridian feature set respectively:

e36cd2cdc9674a7a4855d21fb7b3e6e17c4bb33b
84657efd9116f40924aa13c9d5a349e007da716f

The time reference counter MSR feature was then reverted by commit

1cd4fab14ce25859efa4a2af13475e6650a5506c

because a flaw in the implementation meant the counter was reset on
migration.

All of these changes were made without any addtional options being
added to the VM configuration, or any compatibility checks being made
in the domain save/restore code. Hence setting the single boolean
'viridian' option in the VM configuration yields a different set of
features depending on which version of Xen the VM is started on, and the
feature set can change across migration (so new MSRs can magically appear).

This patch grandfathers in the current viridian features set and calls them
the 'base' and 'freq' feature sets. HVM_PARAM_VIRIDIAN is re-purposed as
a feature mask. The hypervisor has only ever allowed it ot be set to 0
or 1, so the presence of the base and freq sets are indicated by setting
bit 0. The freq set can then be turned off by setting bit 1, thus
restoring the pre-Xen-4.4 base set. Newly implemented viridian features
can be optionally enabled in future by setting further bits.

The viridian option in xl.cfg(5) has also been changed to a list so
that the sets can be individually enabled or disabled. For compatibility,
if the option is specified as a boolean, then a true (1) value will enable
the base and freq sets and a false (0) value will not enable any
enlightenments.

This patch also alters the allowed write accesses to HVM_PARAM_VIRIDIAN.
Currently there is nothing to stop the guest writing this value (which,
while harmless to anything else, should not happen) and nothing to
stop a toolstack from setting the value back to zero whilst the guest is
running, causing CPUID leaves to disappear and MSR accesses to start
causing GPFs in the guest. Both of these possibilities are now disallowed:
Once the parameter is set to a non-zero value it may not be modified (only
re-written with the same value), and guests no longer have any write
access.

Signed-off-by: Paul Durrant <paul.durrant@citrix.com>
Cc: Keir Fraser <keir@xen.org>
Acked-by: Jan Beulich <jbeulich@suse.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: David Scott <dave.scott@eu.citrix.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
x86/viridian: Add partition time reference counter MSR support

This patch optionally re-instates support for the partition time reference
counter that was previously introduced by commit
e36cd2cdc9674a7a4855d21fb7b3e6e17c4bb33b and reverted by commit
1cd4fab14ce25859efa4a2af13475e6650a5506c. The previous implementation was
non-optional and flawed.

This implementation uses the tsc of vcpu0, which is preserved across
save/restore as part of the architectural state, and then converts that
to a 100ns tick using the domain's tsc_khz.

Signed-off-by: Paul Durrant <paul.durrant@citrix.com>
Cc: Keir Fraser <keir@xen.org>
Acked-by: Jan Beulich <jbeulich@suse.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: Christoph Egger <chegger@amazon.de>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
xen: arm: Add support for the Exynos secure firmware

The existence of secure firmware is dictated by the presence of
"samsung,secure-firmware" in the DT.

The Arndale board does not have that entry, and uses the address as defined
in "samsung,exynos4210-sysram", offset 0 as the smp init address. This is
possibly true for all SoCs without secure firmware.

For other boards which do have a "secure-firmware" node, use sysram-ns
at offset +0x1c as the smp init address.

The "secure-firmware" MMIO range contains ways to idle the CPU. As this gets
mapped to DOM0 because of its presence in the DT, we blacklist it.

Have tested this on the Odroid XU. I have also tested the other code path
on the Odroid XU by removing "secure-firmware" from its DT. I could see
that the other code path was exercised with correct smp init address
values.

Signed-off-by: Suriyan Ramasami <suriyan.r@gmail.com>
Tested-by: Ian Campbell <ian.campbell@citrix.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
make: Add subtree-force-update target

subtree-force-update will update all subtrees according to the current TAG specified
in Config.mk.

Signed-off-by: George Dunlap <george.dunlap@eu.citrix.com>
Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
make: Make "src-tarball" target actually make a source tarball

At the moment, making a release tarball is an annoyingly manual
process that involves running "git archive" into a temporary directory.

Script this process up and make a target, so that the release manager
can simply type "make src-tarball-release" and have everything show up
nice and neat in dist/xen-$version.tar.gz.  "make src-tarball" will
make a version number based on git describe, which will typically have
the most recent tag, number of commits since that tag, and the git
commit id of the current HEAD.

Signed-off-by: George Dunlap <george.dunlap@eu.citrix.com>
Add configure --with-initd-dir=DIR

Signed-off-by: Olaf Hering <olaf@aepfle.de>
tools/hotplug: use XEN_SCRIPT_DIR instead of hardcoded path

Helper scripts get installed into XEN_SCRIPT_DIR, but initscripts,
helper scripts and udev rules still refer to the hardcoded location
/etc/xen/scripts/. Update scripts, rules and Makefile to refer to
@XEN_SCRIPT_DIR@ instead.
Update configure.ac to substitute the path in files using XEN_SCRIPT_DIR.
Remove XEN_SCRIPT_DIR from StdGNU.mk and SunOS.mk, its already in
Paths.mk. Note: In SunOS.mk it refered to PRIVATE_PREFIX, which was
likely a typo introduced by 9f6d07bac9f14aaa8bafe38b4a217e61a3a57842
("tools: get rid of hardcoded config dirs")

Signed-off-by: Olaf Hering <olaf@aepfle.de>
tools/configure.ac: sort AC_CONFIG_FILES

Signed-off-by: Olaf Hering <olaf@aepfle.de>
tools: use INITD_DIR instead of CONFIG_DIR/init.d|rc.d

Signed-off-by: Olaf Hering <olaf@aepfle.de>
tools/hotplug: substitute XEN_SCRIPT_DIR on FreeBSD

Also remove DESTDIR from the path, this was most likely not intended.

Signed-off-by: Olaf Hering <olaf@aepfle.de>
remove duplicate variables from config

... because they are already in Paths.mk:
BINDIR, LIBEXEC, PRIVATE_BINDIR, PRIVATE_PREFIX, SBINDIR, SHAREDIR,
XEN_CONFIG_DIR, XENFIRMWAREDIR, XEN_LOCK_DIR, XEN_PAGING_DIR,
XEN_RUN_DIR. Remove unused PKG_XEN_PREFIX, which was also incorrectly
assigned to PRIVATE_PREFIX.

Signed-off-by: Olaf Hering <olaf@aepfle.de>
Use configure --mandir=DIR to set MANDIR

Signed-off-by: Olaf Hering <olaf@aepfle.de>
Use configure --docdir=DIR to set DOCDIR

Signed-off-by: Olaf Hering <olaf@aepfle.de>
Use configure --includedir=DIR to set INCLUDEDIR

Signed-off-by: Olaf Hering <olaf@aepfle.de>
Use configure --libexecdir=BASEDIR to set LIBEXEC

The current usage of LIBEXEC is bogus. It describes the directory for
private xen executables. Other places create their own, similar
libexecdir path as $prefix/lib/xen/*.

Additional two other variables are used to describe similar paths:
PRIVATE_BINDIR and PRIVATE_PREFIX

The autotools configuration refers to libexec as a directory for
executables and stuff which is called by other programs, not by the
user.

Adjust all places that want libexecdir as a target path. LIBEXEC refers
now to the base directory. Three convenience variables are used to refer
to paths to private binaries, libs and include files.

Most users of LIBEXEC are updated to use LIBEXEC_BIN because that is
what they want.

Users of PRIVATE_BINDIR are updated to use LIBEXEC_BIN because that is
what they want.

An internal libxl function was removed. A single helper to retrieve
LIBEXEC_BIN remains.

As suggested by the docs, configure appends the package name to LIBEXEC
to make sure the provided directory really refers to xen. This makes
sure "make uninstall" preserves the real libexecdir.

Signed-off-by: Olaf Hering <olaf@aepfle.de>
Use configure --prefix=DIR to set PREFIX

PREFIX is set by configure --prefix=DIR, nothing outside
tools,docs,stubdom is using this variable.

Signed-off-by: Olaf Hering <olaf@aepfle.de>
Use configure --localstatedir=BASEDIR to set path to /var

This is helpful to test make uninstall with --prefix=/private/dir as
unprivileged user. No change in behaviour is expected by this change.

Signed-off-by: Olaf Hering <olaf@aepfle.de>
Add configure --enable-rpath

This fixes the tools when xen is configured with --prefix=/odd/path

Signed-off-by: Olaf Hering <olaf@aepfle.de>
Add configure --with-linux-backend-modules="mod1 mod2"

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.

Signed-off-by: Olaf Hering <olaf@aepfle.de>
Add configure --with-bash_completion-dir=DIR

Signed-off-by: Olaf Hering <olaf@aepfle.de>