tools: CMDs and APIs for Cache Monitoring Technology

Introduced some new xl commands to enable/disable Cache Monitoring
Technology(CMT) feature.

The following two commands is to attach/detach the CMT feature
to/from a certain domain.

$ xl psr-cmt-attach domid
$ xl psr-cmt-detach domid

This command is to display the CMT information, such as L3 cache
occupancy.

$ xl psr-cmt-show cache_occupancy <domid>

Signed-off-by: Dongxiao Xu <dongxiao.xu@intel.com>
Signed-off-by: Chao Peng <chao.p.peng@linux.intel.com>
Acked-by: Wei Liu <wei.liu2@citrix.com>
docs, amd_ucode: condense amd_ucode notes

Some cleanups to the documentation-
 - Remove unnecessary steps listed to apply ucode using initrd.
 - Condense 'Misc notes' section as well

Suggested-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
Signed-off-by: Aravind Gopalakrishnan <aravind.gopalakrishnan@amd.com>
move XENMEM_get_vnumainfo out of tools-only section of public/memory.h

After all this interface specifically exists for guest kernels to learn
about their (virtual) topology. I'm sure I made a comment to this
effect during review, but apparently I then didn't notice that this
never got carried out.

Signed-off-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
tools/mkrpm: improve version.release handling

An increasing version and/or release number helps to update existing
packages without --force as in "rpm Uvh --force xen.rpm". Instead its
possible to do "rpm -Fvh *.rpm" to update only already installed
packages.

With the current way of calculating version-release it is difficult to
get an increasing release number into the spec file. The release is
always zero unless "make make XEN_VENDORVERSION=`date +.%s`" is used,
which has the bad side effect that xen.gz always gets a different
filename every time.

Since the value of release has no meaning its fine to have an ever
increasing number. This could be either the number of seconds (+%s), or
some representation which could mean something to a human. The change
uses a representation of date+time.

With this change my xen$PKG_SUFFIX.rpm gets as version-release
4.5_unstable-20141007161858, instead of 4.5-unstable$XEN_VENDORVERSION.

Note: to maintain the functionality that "rpm -F xen.rpm" works its also
required that the alphanumerical chars increase. Unfortunately thats not
the case for 4.5-rcN because "r" is smaller than "u"nstable. And going
from 4.5-rcN to 4.5 (or 4.5.N-pre to 4.5.N) may break as well. But there
is nothing we can do about this part.
Once 4.6 opens I suggest to set XEN_EXTRAVERSION to -devel because "d"
is smaller than "r" in 4.6-rcN. But thats a different discussion.

Signed-off-by: Olaf Hering <olaf@aepfle.de>
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>
Cc: George Dunlap <george.dunlap@eu.citrix.com>
Separate runtime debug output from debug symbols

Two make variables exist (debug=y and debug_symbols=y) to control either
the creation of additional runtime debug or the creation of debug
symbols for tools like gdb.  Some places in the code still passed -g
unconditionally to the compiler. Wrap them into a "debug_symbols"
conditional. The xen build passed -g unconditional, reuse the existing
debug_symbols=y check in Config.mk. There are still parts of the code
that hardcode -g, namely the external qemu-traditional and stubdom
packages. They are not changed by this patch.

No change in behaviour is expected by that patch for tools and xen.

Signed-off-by: Olaf Hering <olaf@aepfle.de>
Release-Acked-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Reviewed-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Acked-by: Jan Beulich <jbeulich@suse.com> (for xen/Rules.mk)
Cc: David Scott <dave.scott@eu.citrix.com>
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: Samuel Thibault <samuel.thibault@ens-lyon.org>
Cc: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Cc: Tim Deegan <tim@xen.org>
Cc: Wei Liu <wei.liu2@citrix.com>
Add configure --with-extra-cflags-*

Since commit 338c4375153e39b95ddc82f2ed95f85dd73e0245 ("tools: pass
EXTRA_CFLAGS via environment") it was possible to specify additional
CFLAGS in the environment. That commit gives a good explanation how that
is useful.

Now that we have configure move the knobs from the middle of the source
code to a more prominent place. If the variables are set once via
configure it is possible to rerun make from another shell which may not
have these environment variables. That can happen if one tries to resume
a failed build with either doing chroot into a rpmbuild tree or from
another xterm.

This change adds the configure options --with-extra-cflags-tools=,
--with-extra-cflags-qemu-traditional= and
--with-extra-cflags-qemu-upstream= which will assign their values to the
existing make variables.

It is now required to use configure instead of environment variables to
have a consistent set of CFLAGS across make invocations.

A new knob "skip_extra_cflags" in Rules.mk is recognized to turn off the
assignment to CFLAGS. This is required to build the firmware.

Please rerun autogen.sh after applying this patch.

Signed-off-by: Olaf Hering <olaf@aepfle.de>
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>
tools/hotplug: use configure --sysconfdir result

... instead of hardcoding values and guess where they config files may
be. Also use the result of --with-sysconfig-leaf-dir.

Signed-off-by: Olaf Hering <olaf@aepfle.de>
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>
tools/hotplug: fix systemd service files for dom0

ConditionVirtualization= checks if systemd runs in some sort of guest.
It is not supposed to detect host capabilities. The current
implementation happens to work because systemd-detect-virt from v208
returns also 'xen' in a dom0. In v210 and later 'none' is returned and
all service files are not started.

Adjust the checks to detect a dom0 vs. native boot. Mounting xenfs
depends on /proc/xen, but should only be done for pvops because xenfs
exists only there. All other service files should not be started in
domU. The file /proc/xen/capabilities exists in both dom0 and domU in a
pvops kernel, but only in dom0 it contains 'control_d'. The existing
ExecStartPre= check will prevent starting in a domU.

ConditionVirtualization=!xen is true in a dom0. But this check is broken
in systemd v208, so its not used.

Signed-off-by: Olaf Hering <olaf@aepfle.de>
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>
tools/hotplug: update dependency of var-lib-xenstored.mount

After previous change which uses /proc/xen/capabilities as condition the
unit file has now a dependency on proc-xen.mount. Add a Requires= to let
this unit fail if proc-xen.mount fails. Add an After= as ordering hint.

This was noticed with a pvops dom0, in a xenlinux dom0 the proc file is
always present.

Signed-off-by: Olaf Hering <olaf@aepfle.de>
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>
tools/hotplug: add helper script to visualize systemd dependencies

A small helper to draw a graph with dot(1) and show it with display(1):
bash tools/hotplug/Linux/systemd/show_service_dependencies.sh \
	tools/hotplug/Linux/systemd/*.in

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