These aren't used, and are not obvious useful either.
tools/ does have some logic which works on $(XEN_OS) directly, and some on
CONFIG_$(XEN_OS) too, but this isn't how we typically refer to things.
The only user ever of this scheme (AFAICT) was introduced in
c0fd920e98 (2006) and deleted in fa2244104b (2010).
No functional change.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Oleksii Kurochko <oleksii.kurochko@gmail.com>
Reviewed-by: Alistair Francis <alistair.francis@wdc.com>
Acked-by: Stefano Stabellini <sstabellini@kernel.org>
Tested-by: Jiamei Xie <jiamei.xie@arm.com>
It's not clear why for x86-64 a different approach was used than the
(shorter) one x86-32 has been using. Move the setting to the respective
OS files and reuse x86-32's approach for x86-64, while at the same time
using an OS-independent variable name (thus avoiding the indirection
through $(XEN_OS)).
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Andrew Cooper <andrew.cooper3@citrix.com>
Use the Kconfig generated CONFIG_COMPAT defines in the code base.
Signed-off-by: Doug Goldstein <cardoe@cardoe.com>
Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
CONFIG_HVM is not used anywhere in the build process so drop it.
Signed-off-by: Doug Goldstein <cardoe@cardoe.com>
Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
In preparation to add support for ARM LPAE mem_event, relocate mem_access,
mem_event and auxiliary functions into common Xen code.
This patch makes no functional changes to the X86 side, for ARM mem_event
and mem_access functions are just defined as placeholder stubs, and are
actually enabled later in the series.
Edits that are only header path adjustments:
xen/arch/x86/domctl.c
xen/arch/x86/mm/hap/nested_ept.c
xen/arch/x86/mm/hap/nested_hap.c
xen/arch/x86/mm/mem_paging.c
xen/arch/x86/mm/mem_sharing.c
xen/arch/x86/mm/p2m-pod.c
xen/arch/x86/mm/p2m-pt.c
xen/arch/x86/mm/p2m.c
xen/arch/x86/x86_64/compat/mm.c
xen/arch/x86/x86_64/mm.c
Makefile adjustments for new/removed code:
xen/common/Makefile
xen/arch/x86/mm/Makefile
Relocated prepare_ring_for_helper and destroy_ring_for_helper functions:
xen/include/xen/mm.h
xen/common/memory.c
xen/include/asm-x86/hvm/hvm.h
xen/arch/x86/hvm/hvm.c
Code movement of mem_event and mem_access:
xen/arch/x86/mm/mem_access.c -> xen/common/mem_access.c
xen/arch/x86/mm/mem_event.c -> xen/common/mem_event.c
xen/include/asm-x86/mem_access.h -> xen/include/xen/mem_access.h
xen/include/asm-x86/mem_event.h -> xen/include/xen/mem_event.h
Signed-off-by: Tamas K Lengyel <tklengyel@sec.in.tum.de>
Acked-by: Tim Deegan <tim@xen.org>
These allow an x86_64 hypervisor to build on FreeBSD 9.1/amd64.
- like OpenBSD, needs a different arch passed to ld.
- like OpenBSD, stdarg.h and stdbool.h are in /usr/include.
Signed-off-by: Tim Deegan <tim@xen.org>
Acked-by: Keir Fraser <keir@xen.org>
This is a follow up to "xen: arm: make zImage the default target which we
install".
On ARM the xen.gz binary installed into /boot is not immediately useful because
bootloaders (e.g. u-boot) do not unconditionally support decompression (except
via the uImage wrapper, which we currently do not support via our build system)
Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Acked-by: Keir Fraser <keir@xen.org>
Acked-by: Julien Grall <julien.grall@linaro.org>
Acked-by: Jan Beulich <jbeulich@suse.com>
For build systems which build certain Xen components separately, allow certain
components to be conditionally built based on .config, rather than always
building them.
This patch allows qemu and blktap to be configured in this manner.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
Committed-by: Ian Campbell <ian.campbell@citrix.com>
After commit 25594:ad08cd8e7097, EFI Xen binaries were installed to
/efi instead of /usr/lib64/efi. This patch restores the previous
behaviour established in commit 23645:638f31a30b6c.
Signed-off-by: Matt Wilson <msw@amazon.com>
Reported-by: Olaf Hering <olaf@aepfle.de>
Committed-by: Jan Beulich <jbeulich@suse.com>
Currently shared libraries are automatically installed into /usr/lib
or /usr/lib64, depending on the supplied --prefix value and
$(XEN_TARGET_ARCH). Some systems, like recent Debian and Ubuntu releases,
do not use /usr/lib64, but instead /usr/lib/x86_64-linux-gnu.
With this change, packagers can supply the desired location for shared
libraries on the ./configure command line. Packagers need to note that
the default behaviour on 64-bit Linux systems will be to install shared
libraries in /usr/lib, not /usr/lib64, unless a --libdir value is provided
to ./configure.
Additionally, the libfsimage plugins are now loaded explicitly from
$LIBDIR/fs, removing platform-based decision trees in code.
Signed-off-by: Matt Wilson <msw@amazon.com>
Acked-by: Ian Jackson <Ian.Jackson@eu.citrix.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
[ ijc -- resolve rejects in configure by rerunning autogen.sh. Dropped changes
to remove m4/default_lib.m4 and update m4/pkg.m4 since they cause LIBDIR=/lib
instead of /usr/lib. Reran ./autogen.sh after that too ]
Committed-by: Ian Campbell <ian.campbell@citrix.com>
In the current tree, setting PREFIX does not work very well. This is
because of confusion about the meaning of LIBDIR. In some places it
is the pathname tail of directories containing libraries (lib, lib64
or lib/amd64). But in other places it is a destination pathname
(implicitly, including any PREFIX). This can result in PREFIX or /usr
being added the wrong number of times.
This patch splits LIBDIR into two variables, LIBLEAFDIR and
LIBDIR. LIBDIR is the directory into which Xen libraries and other
similar code is to be placed, and includes any PREFIX. LIBLEAFDIR is
just the library tail and can be appended to various different
prefixes; for example, to construct the X11 library directory for -L.
Neither variable contains the value of DESTDIR, which is of course
used only to redirect the results of `make install' when desired.
Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
1. GNU ld does not understand -m{32,64}. It must be cooked for it by
the GCC driver program.
2. Where GNU ld is directly called we must use -melf_{i386,x86_64}.
3. We cannot avoid calling GNU ld directly in some cases (e.g., when
specifying GNU-specific linker scripts) as on some host
architectures the GCC driver is configured to call the host
linker.
4. We cannot add -melf_{i386,x86_64} to LDFLAGS as the option is
not recognised by GCC.
Hence we define new LDFLAGS_DIRECT, to be added to the command line
only when invoking GNU ld directly.
Signed-off-by: Keir Fraser <keir@xensource.com>
save/restore working in the xen-ia64-unstable.hg thanks to some
excellent work by Tristan. This simply splits the xcutils components
from the x86-ish linux_save/restore files in a way that should be
friendly to powerpc.
Signed-off-by: Alex Williamson <alex.williamson@hp.com>
Andrew Cooper
Jan Beulich
Doug Goldstein
Tamas K Lengyel
Stefano Stabellini
Ian Campbell
Tim Deegan
Matt Wilson
Keir Fraser
Emmanuel Ackaouy
kfraser@localhost.localdomain
kaf24@firebug.cl.cam.ac.uk
kfraser@dhcp93.uk.xensource.com