EFI: update MAINTAINERS after moving of files

I forgot to request this to be done along with the files being moved.

Signed-off-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
xen: arm64: Handle memory banks which are not 1GB aligned

The code in the arm64 version of setup_xenheap_mappings was making
some very confused attempts to handle this but was bogus.

As well as adjusting the mapping to start on a 1GB boundary we also
need to account for the offset between the start of the mapping and
the actual start of the heap when converting between page pointers,
virtual addresses and machine addresses.

I preferred to do this by explicitly accounting for the offset rather
than adding an offset to the frametable because that approach could
potentially waste a large amount of frametable (up to just less than
1GB worth) but also because of issues with converting mfns from
outside the regions considered for pdx initialisation (which are not
1GB aligned) back and forth.

We already have an idea of the distinction between the start of the
direct map and the start of the xenheap in the difference between
DIRECTMAP_VIRT_START and XENHEAP_VIRT_START. Until now these were the
same thing, but now we change XENHEAP_VIRT_START to point to the
actual start of heap not the mapping. Surprisingly there was only one
place which was using the conceptually wrong value.

Also change xenheap_virt_end to a vaddr_t for consistency.

We've been lucky so far that most hardware happens to locate memory
on a 1GB boundary (we did have reports of a system with memory at a
half gig boundary which exhibited failures which I didn't manage to
follow up on successfully). The EFI support has exposed this
shortcoming by the way it handles reserved memory, which has a
similar effect to having memory non-1GB aligned.

arm32 does things differently here due to using a small Xen heap and
a demand mapped domain heap, so isn't affected.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Cc: Suravee Suthikulanit <suravee.suthikulpanit@amd.com>
Cc: Roy Franz <roy.franz@linaro.org>
Cc: Vijay Kilari <vijay.kilari@gmail.com>
Reviewed-by: Julien Grall <julien.grall@linaro.org>
Tested-by: Suravee Suthikulpanit <suravee.suthikulpanit@amd.com>
Roy Franz <roy.franz@linaro.org>
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 a guest is active. 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.
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>