Riku Voipio reports a regression introduced by d0e2772b93 ("Makefile:
allow overriding CFLAGS on the command line"):
| This breaks builds of debian packages as dpkg-buildpackage sets LDFLAGS
| to something unsuitable for guest init.
Revert the problematic patch for the moment, while we rethink how we'd
like to support user-provided toolchain flags.
This reverts commit d0e2772b93.
Conflicts:
Makefile
Signed-off-by: Will Deacon <will.deacon@arm.com>
While we have an LDFLAGS variable in kvmtool's Makefile, it's not
really used when both doing the feature tests and when finally linking
the lkvm executable.
Add that variable to all the linking steps to allow the user to
specify custom library directories or linker options on the command
line.
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
Signed-off-by: Will Deacon <will.deacon@arm.com>
When a Makefile variable is set on the make command line, all
Makefile-internal assignments to that very variable are _ignored_.
Since we add quite some essential values to CFLAGS internally,
specifying some CFLAGS on the command line will usually break the
build (and not fix any include file problems you hoped to overcome
with that).
Somewhat against intuition GNU make provides the "override" directive
to change this behavior; with that assignments in the Makefile get
_appended_ to the value given on the command line. [1]
Change any internal assignments to use that directive, so that a user
can use:
$ make CFLAGS=/path/to/my/include/dir
to teach kvmtool about non-standard header file locations (helpful
for cross-compilation) or to tweak other compiler options.
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
[1] https://www.gnu.org/software/make/manual/html_node/Override-Directive.html
Signed-off-by: Will Deacon <will.deacon@arm.com>
Add the tiny x86/init.S which just mounts /host and execs
/virt/init.
NOTE: of course, the usage of CONFIG_GUEST_PRE_INIT is ugly, we
need to cleanup this code. But I'd prefer to do this on top of
this minimal/simple change. And I think this needs cleanups in
any case, for example I think lkvm shouldn't abuse the "init="
kernel parameter at all.
Acked-by: Pekka Enberg <penberg@kernel.org>
Signed-off-by: Oleg Nesterov <oleg@redhat.com>
Signed-off-by: Will Deacon <will.deacon@arm.com>
This comes as a separate patch because I do not really understand
/usr/bin/make, probably it should be updated.
Change the main Makefile so that if an arch defines ARCH_PRE_INIT
then we
- build $GUEST_INIT without "-static"
- add -DCONFIG_GUEST_PRE_INIT to $CFLAGS
- build $ARCH_PRE_INIT as guest/guest_pre_init.o and embed it
into lkvm the same as we do with guest/guest_init.o
This also means that ARCH_PRE_INIT case doesn't depend on glibc-static,
we can relax the SOURCE_STATIC check later.
Acked-by: Pekka Enberg <penberg@kernel.org>
Signed-off-by: Oleg Nesterov <oleg@redhat.com>
Signed-off-by: Will Deacon <will.deacon@arm.com>
After make lkvm-static & make clean, the dependency files for static
objects (.xxx.static.o.d) are not removed.
Signed-off-by: Xiaochen Shen <xiaochen.shen@intel.com>
Signed-off-by: Dimitri John Ledkov <dimitri.j.ledkov@intel.com>
This is regression issue introduced by patch:
0001-tools-kvm-fix-assumption-of-no-IP-options.patch
This line of code breaks SOURCE_AIO try-build logic
CFLAGS += $(WARNINGS) -DCONFIG_HAS_AIO
The compiling error:
# make lkvm-static
disk/core.static.o: In function `disk_image__thread':
kvmtool/disk/core.c:69: undefined reference to `io_getevents'
disk/core.static.o: In function `disk_image__new':
kvmtool/disk/core.c:112: undefined reference to `io_setup'
util/read-write.static.o: In function `aio_pwritev':
kvmtool/util/read-write.c:332: undefined reference to `io_submit'
util/read-write.static.o: In function `aio_preadv':
kvmtool/util/read-write.c:349: undefined reference to `io_submit'
collect2: error: ld returned 1 exit status
make: *** [lkvm-static] Error 1
Signed-off-by: Xiaochen Shen <xiaochen.shen@intel.com>
Signed-off-by: Dimitri John Ledkov <dimitri.j.ledkov@intel.com>
If one typically only boots full disk-images, one wouldn't necessaraly
want to statically link glibc, for the guest-init feature of the
kvmtool. As statically linked glibc triggers haevy security
maintainance.
Signed-off-by: Dimitri John Ledkov <dimitri.j.ledkov@intel.com>
[will: moved all the guest_init handling into builtin_setup.c]
Signed-off-by: Will Deacon <will.deacon@arm.com>
Currently Makefile accepts only armv7l.* When building kvmtool under 32bit
personality on Aarch64 machines, uname -m reports "armv8l", so build fails.
We expect doing 32bit arm builds in Aarch64 to become standard the same way
people do i386 builds on x86_64 machines.
Make the sed test a little more greedy so armv8l becomes acceptable.
Acked-by: Andre Przywara <andre.przywara@arm.com>
Signed-off-by: Riku Voipio <riku.voipio@linaro.org>
Signed-off-by: Will Deacon <will.deacon@arm.com>
If one typically only boots full disk-images, one wouldn't necessaraly
want to statically link glibc, for the guest-init feature of the
kvmtool. As statically linked glibc triggers haevy security
maintainance.
Signed-off-by: Dimitri John Ledkov <dimitri.j.ledkov@intel.com>
The clang compiler by default dislikes non-literal format strings
in *printf functions, so it complains about kvm__set_dir() in kvm.c
and about the error reporting functions.
Since a fix is not easy and the code itself is fine (just seems that
the compiler is not smart enough to see that), let's just disable
the warning. Since GCC knows about this option as well (it just
doesn't have it enabled with -Wall), we can unconditionally add this
to the warning options.
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
Signed-off-by: Will Deacon <will.deacon@arm.com>
The musl-libc library provides implementations of strlcpy and strlcat,
so introduce a feature check for it and only use the kvmtool
implementation if there is no library support for it.
This avoids clashes with the public definition.
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
Signed-off-by: Will Deacon <will.deacon@arm.com>
Stripping has no effect on object files, so having "-s -c" on the
command line makes no sense.
In fact clang complains about it and aborts with an error, so lets
just remove the unneeded "-s" switch here.
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
Signed-off-by: Will Deacon <will.deacon@arm.com>
We have always built kvmtool as 64-bit on powerpc, but mainly just out
of habit. There's not AFAIK any reason we *can't* build 32-bit.
So fix up a few places where we were assuming 64-bit, and drop the
Makefile logic that forces 64-bit.
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Signed-off-by: Will Deacon <will.deacon@arm.com>
Having ARCH defined to something unknown or trying to compile kvmtool
on an unsupported architecture barfs quite late, actually after
checking for libraries. This gives a lot of messages, but the only
useful one (architecture not supported) is easily overseen.
Abort early if ARCH contains an unknown architecture name.
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
Signed-off-by: Will Deacon <will.deacon@arm.com>
The Makefile checks for the libaries needed to display the guest's
framebuffer unconditionally on all architectures.
However currently only x86 supports a guest framebuffer.
Introduce ARCH_HAS_FRAMEBUFFER in the Makefile and check for the
needed libraries only on x86. If other architectures add support for
it later, we can add them easily.
This avoids pulling in unneeded libraries into the lkvm binary, which
breaks copying over binaries into systems with only minimal userland.
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
Signed-off-by: Will Deacon <will.deacon@arm.com>
kvmtool doesn't build with arbitrary flags, so let's clear CFLAGS and
LDFLAGS by default at the top of the Makefile, allowing people to add
additional options there if they really want to.
Reported by Dave Jones, who ended up passing -std=gnu99 by mistake.
Reported-by: Dave Jones <davej@codemonkey.org.uk>
Signed-off-by: Will Deacon <will.deacon@arm.com>
After building, there is a lot of clutter from the dependency system.
Let's clean this up by using dir/.file.d style dependencies, similar
to those used in the Linux kernel.
In order to support this, rearrange the dependency generation to
create the dependency files as we build rather than as a separate
step, and have make clean remove them.
Signed-off-by: Russell King <rmk@arm.linux.org.uk>
[will: added make target for builtin-help.static.o]
Signed-off-by: Will Deacon <will.deacon@arm.com>
Currently there is a warning when the (highly optional) GTK3 support
cannot be compiled in. Actually many may consider GTK3 the least
interesting of the optional packages, so replace this rather verbose
warning with a brief list of not found optional packages: This will
give a much nicer output like this:
Makefile:291: Skipping optional libraries: bfd GTK3 vncserver aio
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
Signed-off-by: Will Deacon <will.deacon@arm.com>
Instead of hardcoding libfdt availability, check for it like for
the other libraries and fail (and warn) if it's not available.
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
Signed-off-by: Will Deacon <will.deacon@arm.com>
kvmtool used the in-kernel version of the device tree handling
library. Now that we are a proper userland tool, use the system's
library for that purpose. Actually this seems to fix some
long-standing warning generated by the Linux copy.
Also fix up a bogus x86 warning (no FDT needed here).
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
Signed-off-by: Will Deacon <will.deacon@arm.com>
In config/utilities.mak we have two macros checking either
compile-ability or build-ability of a library. Actually they are
defined the same, with try-cc behaving like try-build for no reason.
Fix try-cc to really only test compilation (no linking) and replace
all calls to try-cc in the Makefile with try-build (as this is what
we need). Simplify the Makefile calls a bit on the way.
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
Signed-off-by: Will Deacon <will.deacon@arm.com>
This is not really Linux specific, just a neat implementation
used by kvmtool, too.
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
Signed-off-by: Will Deacon <will.deacon@arm.com>
The Makefile used to reference ../.. on some occasions to point
to the Linux source tree. Since this is no longer there, remove
those bogus paths.
Since we cannot (and don't want to) determine the Linux kernel
version on this way, we hardcode v3.18.0 for now, which is the version
the in-kernel-tree version used at the point of forking.
This should be later revisited and adjusted to whatever versioning
scheme we will use.
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
Signed-off-by: Will Deacon <will.deacon@arm.com>
Currently tools/kvm doesn't build on arm64 when gtk3 is present. The error looks like this:
LINK lkvm
ui/gtk3.o: In function `kvm_gtk_key_press':
/extra/sb/linux-kvm/tools/kvm/ui/gtk3.c:201: undefined reference to `kbd_queue'
/extra/sb/linux-kvm/tools/kvm/ui/gtk3.c:204: undefined reference to `kbd_queue'
/extra/sb/linux-kvm/tools/kvm/ui/gtk3.c:216: undefined reference to `kbd_queue'
/extra/sb/linux-kvm/tools/kvm/ui/gtk3.c:217: undefined reference to `kbd_queue'
/extra/sb/linux-kvm/tools/kvm/ui/gtk3.c:218: undefined reference to `kbd_queue'
ui/gtk3.o:/extra/sb/linux-kvm/tools/kvm/ui/gtk3.c:219: more undefined references to `kbd_queue' follow
collect2: error: ld returned 1 exit status
make: *** [lkvm] Error 1
The patch below makes the error go away and the resulting lkvm runs on arm64.
Cc: Pekka Enberg <penberg@kernel.org>
Signed-off-by: Joel Schopp <joel.schopp@amd.com>
Signed-off-by: Pekka Enberg <penberg@kernel.org>
This patch factors out some of the openfirmware PCI binding definitions
from the powerpc spapr PCI code and uses them to generate appropriate
FDT properties for the PCI node on ARM.
Signed-off-by: Will Deacon <will.deacon@arm.com>
Signed-off-by: Pekka Enberg <penberg@kernel.org>
All architectures are now doing the same thing for irq__alloc_line:
1. Initialise a global counter to some fixed offset
2. Return the current value of the counter and increment it
This is better off in core code, with each architecture specifying the
initial offset, which is specific to the interrupt controller being used
by the guest.
Signed-off-by: Will Deacon <will.deacon@arm.com>
Signed-off-by: Pekka Enberg <penberg@kernel.org>
The ARM V7 and V8 CPUs use the nearly identical support code for generating
timer DT nodes as they both use ARM's architected timers. This code is currently
duplicated for AArch32 and AArch64.
This cleanup patch generalises timer DT node generation to follow the same
pattern as for the GIC. The ability of a DT node to contain multiple compatible
strings is exploited to allow an identical DT node to be used on V7 and V8
platforms.
Acked-by: Will Deacon <will.deacon@arm.com>
Signed-off-by: Jonathan Austin <jonathan.austin@arm.com>
Signed-off-by: Will Deacon <will.deacon@arm.com>
Signed-off-by: Pekka Enberg <penberg@kernel.org>
On powerpc we build kvmtool as a 64bit binary. We do that by setting
-m64 in our CFLAGS. For most things we just call $(CC) and it passes
that info onto the linker.
However there is one place where we explicitly call the linker, in the
build of guest/init - and in that case we need to tell the linker to
build 64bit.
We have gotten away with this so far because we have been building with
a 64bit only toolchain. However if you build with a biarch toolchain,
which generally defaults to 32bit, we fail to link.
The fix is to defined LDFLAGS appropriately and pass it to LD.
Tested on powerpc and x86-64.
Signed-off-by: Michael Ellerman <michael@ellerman.id.au>
Signed-off-by: Pekka Enberg <penberg@kernel.org>
They're hidden inside net/core/iovec.c. It'd be nice to just link to that
but they're not too generic and come with tons of net/ specific code we
don't want. So we just copy over the relevant parts.
Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
Signed-off-by: Pekka Enberg <penberg@kernel.org>
libfdt is used by powerpc, arm and arm64.
This patch factors out the Makefile parts including it and defines a
CONFIG_HAS_LIBFDT, so architecture-portable code can make use of fdt
if it is available.
Signed-off-by: Will Deacon <will.deacon@arm.com>
Signed-off-by: Pekka Enberg <penberg@kernel.org>
It's barely usable but it isn't getting any better sitting alone in a
private git branch.
You can start a new VM with the GTK UI like this:
./vm run --gtk
It's rough around the edges:
- Red and blue color channels are inverted.
- Some keys do not work.
- Mouse does not work.
- GTK assertion failure pops up on shutdown.
but I'm sure there's someone out there that's just dying to improve the
user experience.
Cc: Asias He <asias.hejun@gmail.com>
Cc: Cyrill Gorcunov <gorcunov@openvz.org>
Cc: Ingo Molnar <mingo@kernel.org>
Cc: Sasha Levin <levinsasha928@gmail.com>
Signed-off-by: Pekka Enberg <penberg@kernel.org>
This patch adds support for ARMv8 processors (more specifically,
Cortex-A57) to kvmtool. Both AArch64 and AArch32 guests are supported,
so the existing AArch32 code is slightly restructured to allow for
re-use of much of the current code.
The implementation closely follows the ARMv7 code and reuses much of the
work written there.
Tested-by: Marc Zyngier <marc.zyngier@arm.com>
Signed-off-by: Will Deacon <will.deacon@arm.com>
Signed-off-by: Pekka Enberg <penberg@kernel.org>
ARM has recently published a document describing a firmware interface
for CPU power management, which can be used for booting secondary cores
on an SMP platform, amongst other things. As part of the mach-virt
upstreaming for the kernel (that is, the virtual platform targetted by
kvmtool), it was suggested that we use this interface instead of the
current spin-table based approach.
This patch implements PSCI support in kvmtool for ARM, removing a fair
amount of code in the process.
Signed-off-by: Will Deacon <will.deacon@arm.com>
Signed-off-by: Pekka Enberg <penberg@kernel.org>
This patch adds initial support for ARMv7 processors (more specifically,
Cortex-A15) to kvmtool.
Everything is driven by FDT, including dynamic generation of virtio nodes
for MMIO devices (PCI is not used due to lack of a suitable host-bridge).
The virtual timers and virtual interrupt controller (VGIC) are provided
by the kernel and require very little in terms of userspace code.
Tested-by: Marc Zyngier <marc.zyngier@arm.com>
Signed-off-by: Will Deacon <will.deacon@arm.com>
Signed-off-by: Pekka Enberg <penberg@kernel.org>
PCI devices are currently registered into the pci_devices array via the
pci__register function, which can then be indexed later by architecture
code to construct device tree nodes. For MMIO devices, there is no such
utility.
Rather than invent a similar mechanism for MMIO, this patch creates a
global device registration mechanism, which allows the device type to be
specified when registered or indexing a device. Current users of the pci
registration code are migrated to the new infrastructure and virtio MMIO
devices are registered at init time.
As part of the device registration, allocation of the device number is
moved out of irq__register_device and performed when adding the device
header to the relevant bus tree, allowing us to maintain separate device
numberspaces for each bus.
Signed-off-by: Will Deacon <will.deacon@arm.com>
Signed-off-by: Pekka Enberg <penberg@kernel.org>
A bug only seen with LTO enabled was reported by Ron Minnich. Since the issue
appears to be a linker issue, we disable LTO by default until it's more stable.
We can still run LTO builds by setting LTO=1.
Reported-by: Ron Minnich <rminnich@gmail.com>
Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
Signed-off-by: Pekka Enberg <penberg@kernel.org>
GCC 4.7 with -Wcast-align will warn for code like the following:
bar = (struct foo *)(char *)(0);
which is exactly the sort of code generated by container_of. In
combination with -Werror, this breaks the build.
This patch removes the option from the kvmtool Makefile.
Signed-off-by: Will Deacon <will.deacon@arm.com>
Signed-off-by: Pekka Enberg <penberg@kernel.org>
GNU make defaults "$(CC)" to "cc", which breaks compilation when we try
to execute $(CROSS_COMPILE)-cc.
This patch copies what the top-level kernel Makefile does, by specifying
"gcc" directly when overriding the $CC environment variable.
Signed-off-by: Will Deacon <will.deacon@arm.com>
Signed-off-by: Pekka Enberg <penberg@kernel.org>
Linking dynamically against libbfd results in a non-portable application
binary and is generally frowned upon by distributions: Debian forbids it
explicitly and on Gentoo, it results in a failure at run-time:
./lkvm: error while loading shared libraries: libbfd-2.22.so: cannot
open shared object file: No such file or directory
Avoid these problems by linking statically instead.
Signed-off-by: Will Deacon <will.deacon@arm.com>
Signed-off-by: Pekka Enberg <penberg@kernel.org>
Commit 99423f12db2a ("kvm tools: enable LTO") unconditionally enabled
link-time-optimisations when building kvmtool. Unfortunately, passing
-flto to a GCC without support for the option, results in a fatal build
error:
cc1: error: LTO support has not been enabled in this configuration
This patch adds a check to the kvm tools Makefile so that LTO is only
enabled if the host compiler supports it.
Signed-off-by: Will Deacon <will.deacon@arm.com>
Signed-off-by: Pekka Enberg <penberg@kernel.org>
James Hunt