This file contains a prototype solely used by the BIOS blob code
for x86 systems. Make this clear by moving the include file into
the x86 directory.
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
Signed-off-by: Will Deacon <will.deacon@arm.com>
Two BIOS source files used a definition from <asm/processor-flags.h>,
which could not be found on x86_64 multiarch machines without the
compat headers installed.
Create a file with the single definition actually used in the kvmtool
source tree.
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
Signed-off-by: Will Deacon <will.deacon@arm.com>
This header just holds three trivial functions, but pulls in
linux/types.h, which calls for trouble when compiling BIOS files on
x86-64 multiarch machines.
Remove unnecessary includes and move the definitions into the files
where they are used.
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
Signed-off-by: Will Deacon <will.deacon@arm.com>
The x86 BIOS code included some definitions for the E820 table from
the Linux system headers, but those could not be found on x86_64
multiarch systems without the compat headers installed.
Pull the required definitions into the kvmtool source directory,
removing the reference to <asm/e820.h>.
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
Signed-off-by: Will Deacon <will.deacon@arm.com>
For x86 the files that become the BIOS blob are compiled with -m32.
Although we avoid including any system libraries, we use some headers
from /usr/include, which asks for trouble if compiling on a x86-64
multiarch system (Debian/Ubuntu). Without 32-bit compat headers
installed there, the compiler will not find the right files.
However as the BIOS code is actually a self-contained binary without
any relationship to the Linux userland, it should not use or rely
on Linux system headers.
Replace includes of linux/types.h in BIOS code with asm/bios/types.h,
which simply contains the u{8,16,32,64} data types needed by the code.
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
Signed-off-by: Will Deacon <will.deacon@arm.com>
Although those header files are technically Linux internal, they
hold definitions for x86 hardware related bits (APIC, MPSPEC, VESA).
We just reuse their definitions, so copy those files over.
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
Signed-off-by: Will Deacon <will.deacon@arm.com>
Similarily to the generic uapi/linux/kvm.h, each architecture
carries a kvm.h header in its arch/*/include/uapi/asm directory.
These contain bits for the architecture specific interface.
Since we use many recent features in kvmtool, the system headers
provided by the distribution are usually not up-to-date.
Copy the Linux v4.1-rc6 versions of those files for all supported
architectures into the kvmtool tree to get access to the full glory.
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
Signed-off-by: Will Deacon <will.deacon@arm.com>
This is is usually 0 for most archs. On mips we have two types.
TE (type 0) and MIPS-VZ (type 1). Default to 1 on mips.
Signed-off-by: Andreas Herrmann <andreas.herrmann@caviumnetworks.com>
Signed-off-by: Pekka Enberg <penberg@kernel.org>
The recent introduction of bi-endianness on arm/arm64 had the
odd effect of breaking virtio-pci support on these platforms, as the
device endian field defaults to being VIRTIO_ENDIAN_HOST, which
is the wrong thing to have on a bi-endian capable architecture.
The fix is to check for the endianness on the ioport path the
same way we do it for mmio, which implies passing the vcpu all
the way down. Patch is a bit ugly, but aligns MMIO and ioport nicely.
Tested on arm64 and x86.
Acked-by: Will Deacon <will.deacon@arm.com>
Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
Signed-off-by: Pekka Enberg <penberg@kernel.org>
In order to be able to find out about the endianness of a virtual
CPU, it is necessary to pass a pointer to the kvm_cpu structure
down to the MMIO accessors.
This patch just pushes such pointer as far as required for the
MMIO accessors to have a play with the vcpu.
Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
Signed-off-by: Pekka Enberg <penberg@kernel.org>
This patch changes VIRTIO_DEFAULT_TRANS to take a struct kvm parameter,
allowing architectures to choose the default transport dynamically.
For ARM, this is driven by an arch-specific cmdline option.
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>
Rather than performing all config accesses via ioports, map in a 24-bit
memory-mapped configuration space directly below the PCI MMIO region.
This will allow architectures to support PCI without having to support
legacy ioports in the guest kernel. Instead, kvm tool can forward the
config accesses directly to the relevant ioport config callbacks.
Signed-off-by: Will Deacon <will.deacon@arm.com>
Signed-off-by: Pekka Enberg <penberg@kernel.org>
Architectures without a legacy ioport may wish to emulate one, but not
at address 0x0.
This patch introduces KVM_IOPORT_AREA, which each architecture defines
to be the start of the ioport region (i.e. where port addresses are
offset from).
Signed-off-by: Will Deacon <will.deacon@arm.com>
Signed-off-by: Pekka Enberg <penberg@kernel.org>
Currently, only x86 has architecture command-line options (for setting
the BIOS video mode) however this is likely to become more common in the
future.
This patch adds some simple macros and a struct definition to allow
architectures to augment the command-line options with private
definitions. The BIOS video mode option (--vidmode) is also migrated to
the new framework.
Signed-off-by: Will Deacon <will.deacon@arm.com>
Signed-off-by: Pekka Enberg <penberg@kernel.org>
Running a guest with multiple banks of memory based above 0 causes the
guest_flat_to_host address conversion to fail, as it is assumed that
guest memory addresses are offset linearly from 0.
This patch changes the translation function so that the kvm_mem_bank
structures registered by kvm__register_mem are used to translate guest
addresses, rather than use an offset from the start of host memory.
Signed-off-by: Will Deacon <will.deacon@arm.com>
Signed-off-by: Pekka Enberg <penberg@kernel.org>
Some architectures may provide only a restricted PCI implementation and
therefore prefer MMIO as the transport for virtio devices.
This patch allows the arch backend to specify the default virtio
transport. Some devices (e.g. net) allow the transport to be overriden
by the user and are left alone by this change.
Signed-off-by: Will Deacon <will.deacon@arm.com>
Signed-off-by: Pekka Enberg <penberg@kernel.org>
Move all the non-arch specific members into a generic struct, and the arch specific
members into a arch specific kvm_arch. This prevents code duplication across different
archs.
Signed-off-by: Sasha Levin <levinsasha928@gmail.com>
Signed-off-by: Pekka Enberg <penberg@kernel.org>
On some powerpc platforms we need to make sure we only advertise page
sizes to the guest which are <= the size of the pages backing guest RAM.
So have mmap_hugetblfs() save the hugetblfs page size for us, and also
teach mmap_anon_or_hugetblfs() to set the page size for anonymous mmap.
Acked-by: Matt Evans <matt@ozlabs.org>
Signed-off-by: Michael Ellerman <michael@ellerman.id.au>
Signed-off-by: Pekka Enberg <penberg@kernel.org>
Otherwise I'm getting the following compile problem on my Fedora
machine. The helper is rather taken from linux kernel.
| [cyrill@moon kvm]$ make tags
| x86/include/kvm/barrier.h:11:25: fatal error: asm/barrier.h: No such file or directory compilation terminated.
Acked-by: Ingo Molnar <mingo@kernel.org>
Signed-off-by: Cyrill Gorcunov <gorcunov@openvz.org>
Signed-off-by: Pekka Enberg <penberg@kernel.org>
In case if no firmware used we should put mptables
at repdefined address thus kernel scanner will recognized
it.
For this make a distinction between firmware address
and own bios address.
Reported-by: Sasha Levin <levinsasha928@gmail.com>
Signed-off-by: Cyrill Gorcunov <gorcunov@gmail.com>
Signed-off-by: Pekka Enberg <penberg@kernel.org>
This patch adds a "--firmware" command line option to "vm run". You can use
this to try to boot with SeaBIOS, for example:
./vm run --firmware=/usr/share/seabios/bios.bin \
--disk $HOME/images/debian_lenny_amd64_standard.qcow2
This doesn't boot yet for obvious reasons but at least people can now start to
play with external BIOS images easily.
Acked-by Cyrill Gorcunov <gorcunov@openvz.org>
Cc: Yang Bai <hamo.by@gmail.com>
Cc: Matt Evans <matt@ozlabs.org>
Cc: Ron Minnich <rminnich@gmail.com>
Cc: Anthony Liguori <aliguori@us.ibm.com>
Cc: John Floren <john@jfloren.net>
Cc: Sasha Levin <levinsasha928@gmail.com>
Cc: Asias He <asias.hejun@gmail.com>
Cc: Ingo Molnar <mingo@elte.hu>
Signed-off-by: Pekka Enberg <penberg@kernel.org>
If default guest name is used (which is the default
case) the kvm might end up carrying the pointer to
a name which is allocated on stack.
kvm_cmd_run_init
(on stack) default_name
kvm__init(..., default_name)
kvm->name = default_name
So make it to carry a copy of name.
Signed-off-by: Cyrill Gorcunov <gorcunov@gmail.com>
Signed-off-by: Pekka Enberg <penberg@kernel.org>
* Pekka Enberg <penberg@kernel.org> wrote:
> >In file included from virtio/net.c:3:0:
> >include/kvm/virtio.h: In function ‘virt_queue__available’:
> >include/kvm/virtio.h:42:2: error: dereferencing type-punned pointer will break strict-aliasing rules [-Werror=strict-aliasing]
> It's tools/kvm/include/kvm/virtio.h:
>
> static inline bool virt_queue__available(struct virt_queue *vq)
> {
> if (!vq->vring.avail)
> return 0;
>
> vring_avail_event(&vq->vring) = vq->last_avail_idx;
> return vq->vring.avail->idx != vq->last_avail_idx;
> }
>
> and include/linux/virtio_ring.h:
>
> #define vring_avail_event(vr) (*(__u16 *)&(vr)->used->ring[(vr)->num])
>
> I'm not sure what GCC thinks is wrong there...
i suspect the contrast might be from casting a 'struct
vring_used_elem's 'id' field to type '__u16 *' and dereferencing
it might break GCC alias optimizations, as it makes two uses of
the 'num' field - one the regular 32-bit usage, the other this
weird 16-bit usage.
I think the only sane way to solve this is to do what the kernel
does, to turn off strict aliasing. The patch below does this and
resolves the build bug. Note: i also switched optimization from
-Os to -O2 - the latter is generally the better option for
performance critical code. -Os sometimes produces really weird
code.
The other build problem is that it appears the default GCC
regparm model changed, which highlighted this prototype bug:
x86/bios/e820.c:32:15: error: conflicting types for ‘e820_query_map’
In file included from x86/bios/e820.c:1:0:
include/kvm/e820.h:10:6: note: previous declaration of ‘e820_query_map’ was here
and there are similar problems with other BIOS prototypes.
Resolved via the other bits in the patch below.
Signed-off-by: Ingo Molnar <mingo@elte.hu>
Signed-off-by: Pekka Enberg <penberg@kernel.org>
If a guest's ram_size exceeds KVM_32BIT_GAP_START, the corresponding kvm tool's
virtual address size should be (ram_size + KVM_32BIT_GAP_SIZE), rather than ram_size.
Use macro define KVM_32BIT_MAX_MEM_SIZE instead of magic number "0x100000000ULL".
Signed-off-by: Hongyong Zang <zanghongyong@huawei.com>
Signed-off-by: Pekka Enberg <penberg@kernel.org>
This can be used to get vm status information:
vm is running or paused.
Signed-off-by: Asias He <asias.hejun@gmail.com>
Signed-off-by: Pekka Enberg <penberg@kernel.org>
If some of subsequent calls fails we better to return error
code instead of dying with a message. This is a first step
in getting rid of number of die() calls we have in code.
Signed-off-by: Cyrill Gorcunov <gorcunov@gmail.com>
Signed-off-by: Pekka Enberg <penberg@kernel.org>
The KVM_NR_CPUS define is only really used to statically size the global
kvm_cpus array, which can just as easily be allocated on startup. There is
some checking of the -c <nr cpus> value given against NR_CPUs but this is
later again checked against a dynamically-determined limit from
KVM_CAP_MAX_VCPUS anyway. The hardwired limit is arbitrary and not strictly
necessary.
This patch removes the #define, replacing the statically-sized array with
a malloc; the array is kvm->nrcpus+1 in size so that any iterator can halt
at the end (this is done in kvm_cpu__reboot, which doesn't have access to
a struct kvm* and therefore kvm->nrcpus).
An unused #define in x86/mptable.c is also removed.
Signed-off-by: Matt Evans <matt@ozlabs.org>
Signed-off-by: Pekka Enberg <penberg@kernel.org>
Different architectures will deal with MMIO exits differently. For example,
KVM_EXIT_IO is x86-specific, and I/O cycles are often synthesised by steering
into windows in PCI bridges on other architectures.
This patch calls arch-specific kvm_cpu__emulate_io() and kvm_cpu__emulate_mmio()
from the main runloop's IO and MMIO exit handlers. For x86, these directly
call kvm__emulate_io() and kvm__emulate_mmio() but other architectures will
perform some address munging before passing on the call.
Signed-off-by: Matt Evans <matt@ozlabs.org>
Signed-off-by: Pekka Enberg <penberg@kernel.org>
This allows triggering NMI on guests using 'kvm debug -m [cpu]'.
Please note that the default behaviour of 'kvm debug' dumping guest's cpu
state has been modified to require a '-d'/--dump.
Signed-off-by: Sasha Levin <levinsasha928@gmail.com>
Signed-off-by: Pekka Enberg <penberg@kernel.org>
pci_get_io_space_block() used to grab addresses from
KVM_32BIT_GAP_START + 0x1000000, which is x86-specific. Create a new define,
KVM_PCI_MMIO_AREA, to specify a bus address these allocations can come from.
Signed-off-by: Matt Evans <matt@ozlabs.org>
Signed-off-by: Pekka Enberg <penberg@kernel.org>
Ingo Molnar writes:
On Tue, 6 Dec 2011, Ingo Molnar wrote:
> > FYI, today's version fails to build:
> >
> > In file included from x86/include/kvm/barrier.h:13:0,
> > from virtio/core.c:5:
> > ../../arch/x86/include/asm/system.h:404:1: error: unknown type
> > name ‘bool’
> > make: *** [virtio/core.o] Error 1
> > make: *** Waiting for unfinished jobs....
> >
> > latest Fedora Rawhide.
>
> There's no 'bool' in system.h for 3.2-rc4. Is this something that's
> changed in -tip?
It got introduced by a post-rc4 fix:
e5fd47bfab2d: xen/pm_idle: Make pm_idle be default_idle under Xen.
Fix it by include <stdbool.h> in kvm/barrier.h
Reported-by: Ingo Molnar <mingo@elte.hu>
Signed-off-by: Pekka Enberg <penberg@kernel.org>
Create a new arch-specific subdirectory to contain architecture-specific code
and includes.
The Makefile now adds various arch-specific objects based on detected
architecture. That aside, this patch should only contain code moves. These
include:
- x86-specific kvm_cpu setup, kernel loading, memory setup etc. now in
x86/kvm{-cpu}.c
- BIOS now lives in x86/bios/
- ioport setup
- KVM extensions are asserted in arch-specific kvm.c now, so each architecture
can manage its own dependencies.
- Various architecture-specific #defines are moved into $(ARCH)/include/kvm{-cpu}.h
such as struct kvm_cpu, KVM_NR_CPUS, KVM_32BIT_GAP_SIZE.
Signed-off-by: Matt Evans <matt@ozlabs.org>
Signed-off-by: Pekka Enberg <penberg@kernel.org>
Dimitri John Ledkov