For whatever reason on ARM/arm64 machines kvmtool greets us with quite
some elaborate messages:
  Info: Loaded kernel to 0x80080000 (18704896 bytes)
  Info: Placing fdt at 0x8fe00000 - 0x8fffffff
  Info: virtio-mmio.devices=0x200@0x10000:36

  Info: virtio-mmio.devices=0x200@0x10200:37

  Info: virtio-mmio.devices=0x200@0x10400:38

This is not really useful information for the casual user, so change
those lines to use pr_debug().
This also fixes the long standing line ending issue for the mmio output.
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
Signed-off-by: Will Deacon <will.deacon@arm.com>

Implement firmware image loading for arm and set the boot start address
to the firmware address.

Add an option for the user to specify where to map the firmware.
Signed-off-by: Julien Thierry <julien.thierry@arm.com>
Signed-off-by: Will Deacon <will.deacon@arm.com>

Firmware loading/setup function are in fdt file while it is not very
related to this.

Move them to the file that does the main init/setup for memory.
Signed-off-by: Julien Thierry <julien.thierry@arm.com>
Reviewed-by: Andre Przywara <andre.przywara@arm.com>
Signed-off-by: Will Deacon <will.deacon@arm.com>

Introduce memory types RAM and DEVICE, along with a way for subsystems to
query the global memory banks. This is required by VFIO, which will need
to pin and map guest RAM so that assigned devices can safely do DMA to it.
Depending on the architecture, the physical map is made of either one or
two RAM regions. In addition, this new memory types API paves the way to
reserved memory regions introduced in a subsequent patch.

For the moment we put vesa and ivshmem memory into the DEVICE category, so
they don't have to be pinned. This means that physical devices assigned
with VFIO won't be able to DMA to the vesa frame buffer or ivshmem. In
order to do that, simply changing the type to "RAM" would work. But to
keep the types consistent, it would be better to introduce flags such as
KVM_MEM_TYPE_DMA that would complement both RAM and DEVICE type. We could
then reuse the API for generating firmware information (that is, for x86
bios; DT supports reserved-memory description).
Reviewed-by: Punit Agrawal <punit.agrawal@arm.com>
Signed-off-by: Jean-Philippe Brucker <jean-philippe.brucker@arm.com>
Signed-off-by: Will Deacon <will.deacon@arm.com>

In kvmtool, the terminal has 4 term-devices at most. And these term-devices
can connect to serial8250 or virtio console ports. The kvmtool has a loop
thread to detect the incoming data on these term-devices and then send the
data to guest through serial8250 or virtio console ports. On x86, kvmtool
allow to read data from all 4 term-devices. But on ARM, we only support reading
data from the first term-devices. The data from the other term-devices will
be ignored.

Currently, we're adding the kvmtool support to runv (a kind of hyper container)
with Hyperhq guys. Here we're using 3 serial ports in guest to communicate with
host (Container runtime). On x86, it works fine, but on ARM it could not work.
Because we're using terminal 2 to send/receive control message, but terminal 2
is single direction.

In this case, we change the kvm__arch_read_term for ARM to allow reading data
from all term-devices.
Signed-off-by: Wei Chen <Wei.Chen@arm.com>
Signed-off-by: Will Deacon <will.deacon@arm.com>

The madvise behavior is not a bit field and hence can not be or'ed.
Also madvise_behavior_valid checks the flag using a case statement
hence only one behavior is supposed to be supplied. Call madvise
twice, once for MERGEABLE and once for HUGEPAGE.
Acked-by: Andre Przywara <andre.przywara@arm.com>
Signed-off-by: Stefan Agner <stefan@agner.ch>
Signed-off-by: Will Deacon <will.deacon@arm.com>

open() sets the file osset to the beginning of the file, so there's no
need for an explicit lseek when called in kvm__arch_load_kernel_image.
Signed-off-by: Will Deacon <will.deacon@arm.com>

For some reasons (probably to have easy access to the command line)
the kernel loading for arm and arm64 was located in arm/fdt.c.
Move the routines to kvm.c (where other architectures put it) to
only have real device tree code in fdt.c. We use the pointer in
struct kvm to access the command line string.
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
Signed-off-by: Will Deacon <will.deacon@arm.com>

Currently we unconditionally create a virtual GICv2 in the guest.
Add a --irqchip= parameter to let the user specify a different GIC
type for the guest, when omitting this parameter it still defaults to
--irqchip=gicv2.
For now the only other supported type is --irqchip=gicv3
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
[will: use pr_err instead of fprintf]
Signed-off-by: Will Deacon <will.deacon@arm.com>

Extend the vGIC handling code to potentially deal with different IRQ
chip devices instead of hard-coding the GICv2 in.
We extend most vGIC functions to take a type parameter, but still put
GICv2 in at the top for the time being.
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
Reviewed-by: Marc Zyngier <marc.zyngier@arm.com>
Signed-off-by: Will Deacon <will.deacon@arm.com>

As of 3.14, KVM/arm supports the creation/configuration of the GIC through
a more generic device API, which is now the preferred way to do so.

Plumb the new API in, and allow the old code to be used as a fallback.

[Andre: Rename some functions on the way to differentiate between
creation and initialisation more clearly and fix error path.]
Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
Signed-off-by: Will Deacon <will.deacon@arm.com>

If the host kernel is configured with CONFIG_TRANSPARENT_HUGEPAGE_MADVISE,
it is important to madvise(MADV_HUGEPAGE) the memory region.
Otherwise, the guest won't benefit from using THP.
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>

Use of THP requires that the VMA containing the guest memory is
2MB aligned. Unfortunately, nothing in kvmtool ensures that the
memory is actually aligned, making the use of THP very unlikely.

Just follow what we're already doing for virtio, and expand our
forced alignment to 2M.

* without this patch:
root@muffin-man:~# for i in $(seq 1 5); do ./hackbench 50 process 1000; done
Running with 50*40 (== 2000) tasks.
Time: 113.600
Running with 50*40 (== 2000) tasks.
Time: 108.650
Running with 50*40 (== 2000) tasks.
Time: 110.753
Running with 50*40 (== 2000) tasks.
Time: 116.992
Running with 50*40 (== 2000) tasks.
Time: 117.317

* with this patch:
root@muffin-man:~# for i in $(seq 1 5); do ./hackbench 50 process 1000; done
Running with 50*40 (== 2000) tasks.
Time: 97.613
Running with 50*40 (== 2000) tasks.
Time: 96.111
Running with 50*40 (== 2000) tasks.
Time: 97.090
Running with 50*40 (== 2000) tasks.
Time: 100.820
Running with 50*40 (== 2000) tasks.
Time: 100.298
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>

Now that the dust has settled on the devicetree bindings for the generic
PCI host controller in the Linux kernel, update the node generated by
kvmtool to match what mainline kernels will expect.
Signed-off-by: Will Deacon <will.deacon@arm.com>
Signed-off-by: Pekka Enberg <penberg@kernel.org>

This patch routes guest PCI accesses to kvm__emulate_mmio, rather than
exiting lkvm via a die invocation. The guest command-line is also
updated to prevent the guest from attempting to program the BARs with
new addresses (i.e. probe-only).
Signed-off-by: Will Deacon <will.deacon@arm.com>
Signed-off-by: Pekka Enberg <penberg@kernel.org>

Currently the only use of the periodic timer tick in kvmtool is to
handle reading from stdin. Though functional, this periodic tick can be
problematic on slow (eg FPGA) platforms and can cause low interactivity or
even stop the execution from progressing at all.

This patch removes the periodic tick in favour of a dedicated thread blocked
waiting for input from the console. In order to reflect the new behaviour,
the old 'kvm__arch_periodic_tick' function is renamed to 'kvm__arch_read_term'.

In making this change it is necessary to actively flush the emulated serial
console's output buffer after the guest writes to it, as otherwise flushing
only happens with terminal input. Similarly, it is no longer necessary to
flush the buffer when we process input.
Signed-off-by: Jonathan Austin <jonathan.austin@arm.com>
Acked-by: Marc Zyngier <marc.zyngier@arm.com>
Signed-off-by: Pekka Enberg <penberg@kernel.org>

If we're using the 8250 as a fully-fledged console (i.e. not early
console), then we need to allow input as well as output.
Signed-off-by: Will Deacon <will.deacon@arm.com>
Signed-off-by: Pekka Enberg <penberg@kernel.org>

If we're running a guest with a larger page size than the host,
interesting things start to happen when communicating via a virtio-mmio
device because the idea of buffer alignment between the guest and the
host will be off by the misalignment of the guest memory buffer allocated
by the host. This causes things like the index field of vring.used to
be accessed at different addresses on the guest and the host, leading
to deadlock.

Fix this problem by allocating guest memory aligned to the maximum
possible page size for the architecture (64K).
Signed-off-by: Will Deacon <will.deacon@arm.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>