arm/kvm-cpu: Fix new build warning

GCC 13.1 complains about uninitialized value:

arm/kvm-cpu.c: In function 'kvm_cpu__arch_init':
arm/kvm-cpu.c:119:41: error: 'target' may be used uninitialized [-W

arm/kvm-cpu: Fix new build warning

GCC 13.1 complains about uninitialized value:

arm/kvm-cpu.c: In function 'kvm_cpu__arch_init':
arm/kvm-cpu.c:119:41: error: 'target' may be used uninitialized [-Werror=maybe-uninitialized]
119 | vcpu->cpu_compatible = target->compatible;
| ~~~~~~^~~~~~~~~~~~
arm/kvm-cpu.c:40:32: note: 'target' was declared here
40 | struct kvm_arm_target *target;
| ^~~~~~

This can't happen in practice (we call die() when no target is found), but
initialize the target variable earlier to make GCC happy.

Signed-off-by: Jean-Philippe Brucker <jean-philippe@linaro.org>
Link: https://lore.kernel.org/r/20230606143733.994679-3-jean-philippe@linaro.org
Signed-off-by: Will Deacon <will@kernel.org>

show more ...

arm: Get rid of the ARM_VCPU_FEATURE_FLAGS() macro

The ARM_VCPU_FEATURE_FLAGS() macro sets a feature bit in a rather
convoluted way: if cpu_id is 0, then bit KVM_ARM_VCPU_POWER_OFF is 0,
otherwise i

arm: Get rid of the ARM_VCPU_FEATURE_FLAGS() macro

The ARM_VCPU_FEATURE_FLAGS() macro sets a feature bit in a rather
convoluted way: if cpu_id is 0, then bit KVM_ARM_VCPU_POWER_OFF is 0,
otherwise is set to 1. There's really no need for this indirection,
especially considering that the macro has been changed to return the same
value for both the arm and arm64 architectures. Replace it with a simple
conditional statement in kvm_cpu__arch_init(), which makes it clearer to
understand.

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

show more ...

arm: Move arch specific VCPU features to the arch specific function

KVM_CAP_ARM_EL1_32BIT and KVM_CAP_ARM_PMU_V3 are arm64 specific features.
They are set based on arm64 specific command line option

arm: Move arch specific VCPU features to the arch specific function

KVM_CAP_ARM_EL1_32BIT and KVM_CAP_ARM_PMU_V3 are arm64 specific features.
They are set based on arm64 specific command line options and they target
arm64 hardware features. It makes little sense for kvmtool to set the
features in the code that is shared between arm and arm64. Move the logic
to set the feature bits to the arch specific function
kvm_cpu__select_features(), which is already used by arm64 to set other
arm64 specific features.

Signed-off-by: Alexandru Elisei <alexandru.elisei@arm.com>
Link: https://lore.kernel.org/r/20220412133231.35355-5-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 ...

aarch64: Populate the vCPU struct before target->init()

Move the vCPU structure initialisation before the target->init() call to
keep a reference to the kvm structure during init().
This is require

aarch64: Populate the vCPU struct before target->init()

Move the vCPU structure initialisation before the target->init() call to
keep a reference to the kvm structure during init().
This is required by the pvtime peripheral to reserve a memory region
while the vCPU is beeing initialised.

Reviewed-by: Marc Zyngier <maz@kernel.org>
Signed-off-by: Sebastian Ene <sebastianene@google.com>
Link: https://lore.kernel.org/r/20220313161949.3565171-2-sebastianene@google.com
Signed-off-by: Will Deacon <will@kernel.org>

show more ...

arm: Fail early if KVM_CAP_ARM_PMU_V3 is not supported

pmu__generate_fdt_nodes() checks if the host has support for PMU in a guest
and prints a warning if that's not the case. However, this check is

arm: Fail early if KVM_CAP_ARM_PMU_V3 is not supported

pmu__generate_fdt_nodes() checks if the host has support for PMU in a guest
and prints a warning if that's not the case. However, this check is too
late because the function is called after the VCPU has been created, and
VCPU creation fails if KVM_CAP_ARM_PMU_V3 is not available with a rather
unhelpful error:

$ ./vm run -c1 -m64 -f selftest.flat --pmu
# lkvm run --firmware selftest.flat -m 64 -c 1 --name guest-1039
Info: Placing fdt at 0x80200000 - 0x80210000
Fatal: Unable to initialise vcpu

Move the check for KVM_CAP_ARM_PMU_V3 to kvm_cpu__arch_init() before the
VCPU is created so the user can get a more useful error message. This
also matches the behaviour of KVM_CAP_ARM_EL1_32BIT.

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

show more ...

kvmtool: arm64: Report missing support for 32bit guests

When the host doesn't support 32bit guests, the kvmtool fails
without a proper message on what is wrong. i.e,

$ lkvm run -c 1 Image --aarch3

kvmtool: arm64: Report missing support for 32bit guests

When the host doesn't support 32bit guests, the kvmtool fails
without a proper message on what is wrong. i.e,

$ lkvm run -c 1 Image --aarch32
# lkvm run -k Image -m 256 -c 1 --name guest-105618
Fatal: Unable to initialise vcpu

Given that there is no other easy way to check if the host supports 32bit
guests, it is always good to report this by checking the capability, rather
than leaving the users to hunt this down by looking at the code!

After this patch:

$ lkvm run -c 1 Image --aarch32
# lkvm run -k Image -m 256 -c 1 --name guest-105695
Fatal: 32bit guests are not supported

Reported-by: Sami Mujawar <sami.mujawar@arm.com>
Signed-off-by: Suzuki K Poulose <suzuki.poulose@arm.com>
Acked-by: Marc Zyngier <maz@kernel.org>
Cc: Will Deacon <will@kernel.org>
Link: https://lore.kernel.org/r/20200701142002.51654-1-suzuki.poulose@arm.com
Signed-off-by: Will Deacon <will@kernel.org>

show more ...

arm64: Add SVE support

This patch enables the Scalable Vector Extension for the guest when
the host supports it.

This requires use of the new KVM_ARM_VCPU_FINALIZE ioctl before the
vcpu is runnable

arm64: Add SVE support

This patch enables the Scalable Vector Extension for the guest when
the host supports it.

This requires use of the new KVM_ARM_VCPU_FINALIZE ioctl before the
vcpu is runnable, so a new hook kvm_cpu__configure_features() is
added to provide an appropriate place to do this work.

Signed-off-by: Dave Martin <Dave.Martin@arm.com>
Signed-off-by: Will Deacon <will@kernel.org>

show more ...

arm/arm64: Factor out ptrauth vcpu feature setup

In the interest of readability, factor out the vcpu feature setup
for ptrauth into a separate function.

Also, because aarch32 doesn't have this feat

arm/arm64: Factor out ptrauth vcpu feature setup

In the interest of readability, factor out the vcpu feature setup
for ptrauth into a separate function.

Also, because aarch32 doesn't have this feature or the related
command line options anyway, move the actual code into aarch64/.

Since ARM_VCPU_PTRAUTH_FEATURE is only there to make the ptrauth
feature setup code compile on arm, it is no longer needed: inline
and remove it.

Signed-off-by: Dave Martin <Dave.Martin@arm.com>
Signed-off-by: Will Deacon <will@kernel.org>

show more ...

KVM: arm/arm64: Add a vcpu feature for pointer authentication

This patch adds a runtime capabality for KVM tool to enable Arm64 8.3
Pointer Authentication in guest kernel. Two vcpu features
KVM_ARM_

KVM: arm/arm64: Add a vcpu feature for pointer authentication

This patch adds a runtime capabality for KVM tool to enable Arm64 8.3
Pointer Authentication in guest kernel. Two vcpu features
KVM_ARM_VCPU_PTRAUTH_[ADDRESS/GENERIC] are supplied together to enable
Pointer Authentication in KVM guest after checking the capability.

Reviewed-by: Andre Przywara <andre.przywara@arm.com>
Signed-off-by: Amit Daniel Kachhap <amit.kachhap@arm.com>
Signed-off-by: Dave Martin <Dave.Martin@arm.com> [merge new kernel heaers]
Signed-off-by: Will Deacon <will@kernel.org>

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

kvmtool: ARM/ARM64: Provide PSCI-0.2 to guest when KVM supports it

If in-kernel KVM support PSCI-0.2 emulation then we should set
KVM_ARM_VCPU_PSCI_0_2 feature for each guest VCPU and also
provide "

kvmtool: ARM/ARM64: Provide PSCI-0.2 to guest when KVM supports it

If in-kernel KVM support PSCI-0.2 emulation then we should set
KVM_ARM_VCPU_PSCI_0_2 feature for each guest VCPU and also
provide "arm,psci-0.2","arm,psci" as PSCI compatible string.

This patch updates kvm_cpu__arch_init() and setup_fdt() as
per above.

Signed-off-by: Pranavkumar Sawargaonkar <pranavkumar@linaro.org>
Signed-off-by: Anup Patel <anup.patel@linaro.org>
Reviewed-by: Andre Przywara <andre.przywara@arm.com>
Signed-off-by: Will Deacon <will.deacon@arm.com>

show more ...

kvmtool: ARM: Use KVM_ARM_PREFERRED_TARGET vm ioctl to determine target cpu

Instead, of trying out each and every target type we should
use KVM_ARM_PREFERRED_TARGET vm ioctl to determine target type

kvmtool: ARM: Use KVM_ARM_PREFERRED_TARGET vm ioctl to determine target cpu

Instead, of trying out each and every target type we should
use KVM_ARM_PREFERRED_TARGET vm ioctl to determine target type
for KVM ARM/ARM64.

If KVM_ARM_PREFERRED_TARGET vm ioctl fails then we fallback to
old method of trying all known target types.

If KVM_ARM_PREFERRED_TARGET vm ioctl succeeds but the returned
target type is not known to KVMTOOL then we forcefully init
VCPU with target type returned by KVM_ARM_PREFERRED_TARGET vm ioctl.

Signed-off-by: Pranavkumar Sawargaonkar <pranavkumar@linaro.org>
Signed-off-by: Anup Patel <anup.patel@linaro.org>
Reviewed-by: Andre Przywara <andre.przywara@arm.com>
Signed-off-by: Will Deacon <will.deacon@arm.com>

show more ...

kvmtool: virtio: pass trapped vcpu to IO accessors

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 fi

kvmtool: virtio: pass trapped vcpu to IO accessors

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>

show more ...

kvmtool: pass trapped vcpu to MMIO accessors

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 access

kvmtool: pass trapped vcpu to MMIO accessors

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>

show more ...

kvm tools: ARM: allow potential relocation of IO port

Whilst our IO port is fixed at CPU physical address 0x0, changing
ARM_IOPORT_AREA should be all that's necessary to move it around in CPU
physic

kvm tools: ARM: allow potential relocation of IO port

Whilst our IO port is fixed at CPU physical address 0x0, changing
ARM_IOPORT_AREA should be all that's necessary to move it around in CPU
physical space (it will still be at 0x0 in the bus address space).

This patch ensures we subtract KVM_IOPORT_AREA from the faulting CPU
physical address when calculating the port for kvm__emulate_io.

Reported-by: Arnd Bergmann <arnd@arndb.de>
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: 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: add CPU compatible string to target structure

Instead of hardcoding the CPU compatible string, store it in
the target descriptor. This allows similar CPUs to be managed
by the same b

kvm tools: arm: add CPU compatible string to target structure

Instead of hardcoding the CPU compatible string, store it in
the target descriptor. This allows similar CPUs to be managed
by the same backend, and yet have different compatible
properties.

Also remove a check for a condition that can never occur in both
A15 and A57 backends.

Signed-off-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 ...

kvm tools: arm: don't crash when no compatible CPU is found

If the kernel against which kvm tools was compiled supports more
CPU types than kvm tools does, then we can hit a situation where
we deref

kvm tools: arm: don't crash when no compatible CPU is found

If the kernel against which kvm tools was compiled supports more
CPU types than kvm tools does, then we can hit a situation where
we dereference an empty target slot.

Just stepping over empty slots fixes the issue.

Signed-off-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 ...

kvm tools: arm: add support for PSCI firmware in place of spin-tables

ARM has recently published a document describing a firmware interface
for CPU power management, which can be used for booting se

kvm tools: arm: add support for PSCI firmware in place of spin-tables

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>

show more ...

kvm tools: add support for ARMv7 processors

This patch adds initial support for ARMv7 processors (more specifically,
Cortex-A15) to kvmtool.

Everything is driven by FDT, including dynamic generatio

kvm tools: add support for ARMv7 processors

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>

show more ...