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>
Instead of referring to the Linux header including the barrier
macros, copy over the rather simple implementation for the PowerPC
barrier instructions kvmtool uses. This fixes build for powerpc.
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>
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>
The _FDT macro is useful when generating device trees for a guest, so
make it available to other architectures.
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>
Commit 82ea06e "Introduce KVM_VIRTIO_MMIO_AREA" did just that, but only
for x86. Causing the following commit 5c301a3 "Add virtio-mmio support"
to break the build for powerpc.
We follow what x86 did and place it 16MB past the PCI area, I have no
idea if that is actually a good idea, or whether it works at all.
Signed-off-by: Michael Ellerman <michael@ellerman.id.au>
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>
This is the final piece of the puzzle for PPC SPAPR PCI; this
function splits MMIO accesses into the two PHB windows & directs
things to MMIO/IO emulation as appropriate.
Signed-off-by: Matt Evans <matt@ozlabs.org>
Signed-off-by: Pekka Enberg <penberg@kernel.org>
This provides the PCI bridge, definitions for the address layout of the windows
and wires in IRQs. Once PCI devices are all registered, they are enumerated and
DT nodes generated for each.
Signed-off-by: Matt Evans <matt@ozlabs.org>
Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Signed-off-by: Pekka Enberg <penberg@kernel.org>
This patch adds XICS emulation code (heavily borrowed from QEMU), and wires
this into kvm_cpu__irq() to fire a CPU IRQ via KVM. A device tree entry is
also added. IPIs work, xics_alloc_irqnum() is added to allocate an external
IRQ (which will later be used by the PHB PCI code) and finally, kvm__irq_line()
can be called to raise an IRQ on XICS.
Signed-off-by: Matt Evans <matt@ozlabs.org>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Signed-off-by: Pekka Enberg <penberg@kernel.org>
The generated DT is the bare minimum structure required for SPAPR (on which
subsequent patches for VIO, XICS, PCI etc. will build); root node, cpus, memory.
The DT contains CPU-specific configuration; a very simple 'cpu info' mechanism
is added to recognise/differentiate DT entries for POWER7 and PPC970 host CPUs.
Future support of more CPUs is possible.
libfdt is included from scripts/dtc/libfdt.
Signed-off-by: Matt Evans <matt@ozlabs.org>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Signed-off-by: Pekka Enberg <penberg@kernel.org>
Allocate a page table and point SDR1 to it in order to support the -PR
PPC64 KVM mode. (The alternative, -HV mode, is available only on a small
set of machines.)
This patch also removes the previous dependency on mapping guest RAM with
huge pages; PR KVM doesn't require them so the user isn't forced to use them.
A new option, '--hugetlbfs default', uses a default path for 16M pages for
HV mode, if required.
Signed-off-by: Matt Evans <matt@ozlabs.org>
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>
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>
This patch adds a new arch directory, powerpc, basic file structure, register
setup and where necessary stubs out arch-specific functions (e.g. interrupts,
runloop exits) that later patches will provide. The target is an
SPAPR-compliant PPC64 machine (i.e. pSeries); there is no support for PPC32 or
'bare metal' PPC64 guests as yet. Subsequent patches implement the hcalls and
RTAS required to boot SPAPR pSeries kernels.
Memory is mapped from hugetlbfs (as that is currently required by upstream PPC64
HV-mode KVM). The mapping of a VRMA region is yet to be implemented; this is
only necessary on processors that don't support VRMA, e.g. <= P6. Work is
therefore needed to get this going on pre-P7 CPUs.
Processor state is set up as a guest kernel would expect (both primary and
secondaries), and SMP is fully supported.
Finally, support is added for simply loading flat binary kernels (plus initrd).
(bzImages are not used on PPC, and this series does not add zImage support or an
ELF loader.) The intention is to later support loading firmware such as SLOF.
Signed-off-by: Matt Evans <matt@ozlabs.org>
Signed-off-by: Pekka Enberg <penberg@kernel.org>
Michael Ellerman