Add virtio-transport option and deprecate force-pci and virtio-legacy.

This is a follow-up patch for [0] which proposed the --force-pci option
for riscv. As per the discussion it was concluded to ad

Add virtio-transport option and deprecate force-pci and virtio-legacy.

This is a follow-up patch for [0] which proposed the --force-pci option
for riscv. As per the discussion it was concluded to add virtio-tranport
option taking in four options (pci, pci-legacy, mmio, mmio-legacy).

With this change force-pci and virtio-legacy are both deprecated and
arm's default transport changes from MMIO to PCI as agreed in [0].
This is also true for riscv.

Nothing changes for other architectures.

[0]: https://lore.kernel.org/all/20230118172007.408667-1-rkanwal@rivosinc.com/

Signed-off-by: Rajnesh Kanwal <rkanwal@rivosinc.com>
Link: https://lore.kernel.org/r/20230320143344.404307-1-rkanwal@rivosinc.com
Signed-off-by: Will Deacon <will@kernel.org>

show more ...

virtio: Add support for modern virtio-mmio

Add modern MMIO transport to virtio, make it the default. Legacy transport
can be enabled with --virtio-legacy. The main change for MMIO is the queue
addre

virtio: Add support for modern virtio-mmio

Add modern MMIO transport to virtio, make it the default. Legacy transport
can be enabled with --virtio-legacy. The main change for MMIO is the queue
addresses. They are now 64-bit addresses instead of 32-bit PFNs. Apart
from that all changes for supporting modern devices are already
implemented.

Signed-off-by: Jean-Philippe Brucker <jean-philippe.brucker@arm.com>
Link: https://lore.kernel.org/r/20220701142434.75170-11-jean-philippe.brucker@arm.com
Signed-off-by: Will Deacon <will@kernel.org>

show more ...

virtio: Add support for modern virtio-pci

Add support for modern virtio-pci implementation (based on the 1.0 virtio
spec). We add a new transport, alongside MMIO and PCI-legacy. This is now
the defa

virtio: Add support for modern virtio-pci

Add support for modern virtio-pci implementation (based on the 1.0 virtio
spec). We add a new transport, alongside MMIO and PCI-legacy. This is now
the default when selecting PCI, but users can still select the legacy
transport for all virtio devices by passing "--virtio-legacy" on the
command-line.

The main change in modern PCI is the way we address virtqueues, using
64-bit values instead of PFNs. To keep the queue configuration atomic the
device also gets a "queue enable" register. Configuration is also made
extensible by more feature bits and PCI capabilities. Scalability is
improved as well, as devices can have notification registers for each
virtqueue on separate pages. However this implementation keeps a single
notification register.

Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
Signed-off-by: Jean-Philippe Brucker <jean-philippe.brucker@arm.com>
Link: https://lore.kernel.org/r/20220701142434.75170-9-jean-philippe.brucker@arm.com
Signed-off-by: Will Deacon <will@kernel.org>

show more ...

arm/arm64: Kill the ARM_HIMAP_MAX_MEMORY() macro

The ARM_HIMAP_MAX_MEMORY() is a remnant of a time when KVM only supported
40 bits if IPA. There are no users left for this macro, remove it.

Reviewe

arm/arm64: Kill the ARM_HIMAP_MAX_MEMORY() macro

The ARM_HIMAP_MAX_MEMORY() is a remnant of a time when KVM only supported
40 bits if IPA. There are no users left for this macro, remove it.

Reviewed-by: Andre Przywara <andre.przywara@arm.com>
Signed-off-by: Alexandru Elisei <alexandru.elisei@arm.com>
Reviewed-and-Tested-by: Suzuki K Poulose <suzuki.poulose@arm.com>
Link: https://lore.kernel.org/r/20220616134828.129006-8-alexandru.elisei@arm.com
Signed-off-by: Will Deacon <will@kernel.org>

show more ...

arm64: Add --vcpu-affinity command line argument

Add a new command line argument, --vcpu-affinity, to set the CPU affinity
for the VCPUs. The affinity is expressed as a cpulist and will apply to all

arm64: Add --vcpu-affinity command line argument

Add a new command line argument, --vcpu-affinity, to set the CPU affinity
for the VCPUs. The affinity is expressed as a cpulist and will apply to all
VCPU threads.

This gives the user a second option for choosing the PMU on a heterogeneous
system. The PMU setup code, when --vcpu-affinity is specified, will search
for the PMU associated with the CPUs specified with this command line
argument instead of the PMU associated with the CPU on which the main
thread is executing.

Signed-off-by: Alexandru Elisei <alexandru.elisei@arm.com>
Link: https://lore.kernel.org/r/20220412133231.35355-12-alexandru.elisei@arm.com
Signed-off-by: Will Deacon <will@kernel.org>

show more ...

aarch64: Add stolen time support

This patch adds support for stolen time by sharing a memory region
with the guest which will be used by the hypervisor to store the stolen
time information. Reserve

aarch64: Add stolen time support

This patch adds support for stolen time by sharing a memory region
with the guest which will be used by the hypervisor to store the stolen
time information. Reserve a 64kb MMIO memory region after the RTC peripheral
to be used by pvtime. The exact format of the structure stored by the
hypervisor is described in the ARM DEN0057A document.

Reviewed-by: Alexandru Elisei <alexandru.elisei@arm.com>
Tested-by: Alexandru Elisei <alexandru.elisei@arm.com>
Signed-off-by: Sebastian Ene <sebastianene@google.com>
Link: https://lore.kernel.org/r/20220313161949.3565171-3-sebastianene@google.com
Signed-off-by: Will Deacon <will@kernel.org>

show more ...

arm/arm64: Add PCI Express 1.1 support

PCI Express comes with an extended addressing scheme, which directly
translated into a bigger device configuration space (256->4096 bytes)
and bigger PCI confi

arm/arm64: Add PCI Express 1.1 support

PCI Express comes with an extended addressing scheme, which directly
translated into a bigger device configuration space (256->4096 bytes)
and bigger PCI configuration space (16->256 MB), as well as mandatory
capabilities (power management [1] and PCI Express capability [2]).

However, our virtio PCI implementation implements version 0.9 of the
protocol and it still uses transitional PCI device ID's, so we have
opted to omit the mandatory PCI Express capabilities. For VFIO, the power
management and PCI Express capability are left for a subsequent patch.

[1] PCI Express Base Specification Revision 1.1, section 7.6
[2] PCI Express Base Specification Revision 1.1, section 7.8

Signed-off-by: Alexandru Elisei <alexandru.elisei@arm.com>
Reviewed-by: Andre Przywara <andre.przywara@arm.com>
Link: https://lore.kernel.org/r/20210713170631.155595-4-alexandru.elisei@arm.com
Signed-off-by: Will Deacon <will@kernel.org>

show more ...

hw/rtc: ARM/arm64: Use MMIO at higher addresses

Using the RTC device at its legacy I/O address as set by IBM in 1981
was a kludge we used for simplicity on ARM platforms as well.
However this impose

hw/rtc: ARM/arm64: Use MMIO at higher addresses

Using the RTC device at its legacy I/O address as set by IBM in 1981
was a kludge we used for simplicity on ARM platforms as well.
However this imposes problems due to their missing alignment and overlap
with the PCI I/O address space.

Now that we can switch a device easily between using ioports and
MMIO, let's move the RTC out of the first 4K of memory on ARM platforms.

That should be transparent for well behaved guests, since the change is
naturally reflected in the device tree.

Signed-off-by: Andre Przywara <andre.przywara@arm.com>
Reviewed-by: Alexandru Elisei <alexandru.elisei@arm.com>
Link: https://lore.kernel.org/r/20210315153350.19988-23-andre.przywara@arm.com
Signed-off-by: Will Deacon <will@kernel.org>

show more ...

hw/serial: ARM/arm64: Use MMIO at higher addresses

Using the UART devices at their legacy I/O addresses as set by IBM in
1981 was a kludge we used for simplicity on ARM platforms as well.
However th

hw/serial: ARM/arm64: Use MMIO at higher addresses

Using the UART devices at their legacy I/O addresses as set by IBM in
1981 was a kludge we used for simplicity on ARM platforms as well.
However this imposes problems due to their missing alignment and overlap
with the PCI I/O address space.

Now that we can switch a device easily between using ioports and MMIO,
let's move the UARTs out of the first 4K of memory on ARM platforms.

That should be transparent for well behaved guests, since the change is
naturally reflected in the device tree. Even "earlycon" keeps working,
as the stdout-path property is adjusted automatically.

People providing direct earlycon parameters via the command line need to
adjust it to: "earlycon=uart,mmio,0x1000000".

Signed-off-by: Andre Przywara <andre.przywara@arm.com>
Reviewed-by: Alexandru Elisei <alexandru.elisei@arm.com>
Link: https://lore.kernel.org/r/20210315153350.19988-22-andre.przywara@arm.com
Signed-off-by: Will Deacon <will@kernel.org>

show more ...

arm: Reorganise and document memory map

The hardcoded memory map we expose to a guest is currently described
using a series of partially interconnected preprocessor constants,
which is hard to read

arm: Reorganise and document memory map

The hardcoded memory map we expose to a guest is currently described
using a series of partially interconnected preprocessor constants,
which is hard to read and follow.

In preparation for moving the UART and RTC to some different MMIO
region, document the current map with some ASCII art, and clean up the
definition of the sections.

This changes the only internally used value of ARM_MMIO_AREA, to better
align with its actual meaning and future extensions.

No functional change.

Signed-off-by: Andre Przywara <andre.przywara@arm.com>
Reviewed-by: Alexandru Elisei <alexandru.elisei@arm.com>
Link: https://lore.kernel.org/r/20210315153350.19988-21-andre.przywara@arm.com
Signed-off-by: Will Deacon <will@kernel.org>

show more ...

Add emulation for CFI compatible flash memory

The EDK II UEFI firmware implementation requires some storage for the EFI
variables, which is typically some flash storage.
Since this is already suppor

Add emulation for CFI compatible flash memory

The EDK II UEFI firmware implementation requires some storage for the EFI
variables, which is typically some flash storage.
Since this is already supported on the EDK II side, we add a CFI flash
emulation to kvmtool.
This is backed by a file, specified via the --flash or -F command line
option. Any flash writes done by the guest will immediately be reflected
into this file (kvmtool mmap's the file).
The flash will be limited to the nearest power-of-2 size, so only the
first 2 MB of a 3 MB file will be used.

This implements a CFI flash using the "Intel/Sharp extended command
set", as specified in:
- JEDEC JESD68.01
- JEDEC JEP137B
- Intel Application Note 646
Some gaps in those specs have been filled by looking at real devices and
other implementations (QEMU, Linux kernel driver).

At the moment this relies on DT to advertise the base address of the
flash memory (mapped into the MMIO address space) and is only enabled
for ARM/ARM64. The emulation itself is architecture agnostic, though.

This is one missing piece toward a working UEFI boot with kvmtool on
ARM guests, the other is to provide writable PCI BARs, which is WIP.

Tested-by: Ard Biesheuvel <ardb@kernel.org>
Signed-off-by: Raphael Gault <raphael.gault@arm.com>
[Andre: rewriting and fixing]
Signed-off-by: Andre Przywra <andre.przywara@arm.com>
Signed-off-by: Will Deacon <will@kernel.org>

show more ...

ioeventfd: Don't register on the PIO bus if the arch doesn't support it

virtio/pci.c registers a notification ioeventfd on both PIO and MMIO
buses. But architectures other than x86 cannot differenti

ioeventfd: Don't register on the PIO bus if the arch doesn't support it

virtio/pci.c registers a notification ioeventfd on both PIO and MMIO
buses. But architectures other than x86 cannot differentiate MMIO from
PIO traps, and the kernel always calls kvm_io_bus_read/write with
KVM_MMIO_BUS as argument.

As a result kvmtool's ioeventfd isn't used with virtio PCI, because the
kernel can't find it and all accesses to the doorbell return to
userspace. To fix it, don't set the PIO flag if the architecture doesn't
support it.

Fixes: a508ea95f954 ("virtio/pci: Use port I/O for configuration registers by default")
Signed-off-by: Jean-Philippe Brucker <jean-philippe.brucker@arm.com>
Signed-off-by: Will Deacon <will.deacon@arm.com>

show more ...

arm: allow vGICv3 emulation

KVM/arm recently got support for vGICv3 (and vITS), which is evident
in the updated header file. So as now ARM has feature parity when it
comes to the GIC emulation, we c

arm: allow vGICv3 emulation

KVM/arm recently got support for vGICv3 (and vITS), which is evident
in the updated header file. So as now ARM has feature parity when it
comes to the GIC emulation, we can remove the special defines we had
in place to allow compilation for ARM(32).
For simplicity we now use 64K sized GIC regions everywhere, as GICv3
mandates them.
[Andre: some update, reword commit message]

Acked-by: Marc Zyngier <marc.zyngier@arm.com>
Signed-off-by: Vladimir Murzin <vladimir.murzin@arm.com>
Acked-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>

show more ...

arm: add support for supplying GICv3 redistributor addresses

Instead of the GIC virtual CPU interface an emulated GICv3 needs to
have accesses to its emulated redistributors trapped in the guest.
Ad

arm: add support for supplying GICv3 redistributor addresses

Instead of the GIC virtual CPU interface an emulated GICv3 needs to
have accesses to its emulated redistributors trapped in the guest.
Add code to tell the kernel about the mapping if a GICv3 emulation was
requested by the user.

This contains some defines which are not (yet) in the (32 bit) header
files to allow compilation for ARM.

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>

show more ...

arm: simplify MMIO dispatching

Currently we separate any incoming MMIO request into one of the ARM
memory map regions and take care to spare the GIC.
It turns out that this is unnecessary, as we onl

arm: simplify MMIO dispatching

Currently we separate any incoming MMIO request into one of the ARM
memory map regions and take care to spare the GIC.
It turns out that this is unnecessary, as we only have one special
region (the IO port area in the first 64 KByte). The MMIO rbtree
takes care about unhandled MMIO ranges, so we can simply drop all the
special range checking (except that for the IO range) in
kvm_cpu__emulate_mmio().
As the GIC is handled in the kernel, a GIC MMIO access should never
reach userland (and we don't know what to do with it anyway).
This lets us delete some more code and simplifies future extensions
(like expanding the GIC regions).
To be in line with the other architectures, move the now simpler
code into a header file.

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>

show more ...

kvm tools: Provide per arch macro to specify type for KVM_CREATE_VM

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-of

kvm tools: Provide per arch macro to specify type for KVM_CREATE_VM

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>

show more ...

kvmtool: virtio: enable arm/arm64 support for bi-endianness

Implement the kvm_cpu__get_endianness call for both AArch32 and
AArch64, and advertise the bi-endianness support.

Signed-off-by: Marc Zyn

kvmtool: virtio: enable arm/arm64 support for bi-endianness

Implement the kvm_cpu__get_endianness call for both AArch32 and
AArch64, and advertise the bi-endianness support.

Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
Signed-off-by: Pekka Enberg <penberg@kernel.org>

show more ...

kvm tools: ARM: allow default virtio transport to be passed on cmdline

This patch changes VIRTIO_DEFAULT_TRANS to take a struct kvm parameter,
allowing architectures to choose the default transport

kvm tools: ARM: allow default virtio transport to be passed on cmdline

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>

show more ...

kvm tools: ARM: route guest PCI accesses to the emulation layer

This patch routes guest PCI accesses to kvm__emulate_mmio, rather than
exiting lkvm via a die invocation. The guest command-line is al

kvm tools: ARM: route guest PCI accesses to the emulation layer

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>

show more ...

kvm tools: irq: make irq__alloc_line generic

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

kvm tools: irq: make irq__alloc_line generic

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>

show more ...

kvm tools: pci: register 24-bit configuration space below MMIO region

Rather than performing all config accesses via ioports, map in a 24-bit
memory-mapped configuration space directly below the PCI

kvm tools: pci: register 24-bit configuration space below MMIO region

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>

show more ...

kvm tools: allow ioports to be offset from 0

Architectures without a legacy ioport may wish to emulate one, but not
at address 0x0.

This patch introduces KVM_IOPORT_AREA, which each architecture de

kvm tools: allow ioports to be offset from 0

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>

show more ...

kvm tools: arm: add ioport window to virtual memory map

Whilst ARM neither needs or wants a complete x86 legacy ioport emulation,
the 8250 is a useful alternative to virtio-console, so carve out 64k

kvm tools: arm: add ioport window to virtual memory map

Whilst ARM neither needs or wants a complete x86 legacy ioport emulation,
the 8250 is a useful alternative to virtio-console, so carve out 64k at the
bottom of our virtual memory map where we can add ioports if we choose.

Signed-off-by: Will Deacon <will.deacon@arm.com>
Signed-off-by: Pekka Enberg <penberg@kernel.org>

show more ...

kvm tools: arm: align guest memory buffer to maximum page size

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

kvm tools: arm: align guest memory buffer to maximum page size

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>

show more ...

kvm tools: add support for ARMv8 processors

This patch adds support for ARMv8 processors (more specifically,
Cortex-A57) to kvmtool. Both AArch64 and AArch32 guests are supported,
so the existing AA

kvm tools: add support for ARMv8 processors

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>

show more ...