Replace printf/fprintf with pr_* macros

To prepare for allowing finer control over the messages that kvmtool
displays, replace printf() and fprintf() with the pr_* macros.

Minor changes were made t

Replace printf/fprintf with pr_* macros

To prepare for allowing finer control over the messages that kvmtool
displays, replace printf() and fprintf() with the pr_* macros.

Minor changes were made to fix coding style issues that were pet peeves for
the author. And use pr_err() in kvm_cpu__init() instead of pr_warning() for
fatal errors.

Also, fix the message when printing the exit code for KVM_EXIT_UNKNOWN by
removing the '0x' part, because it's printing a decimal number, not a
hexadecimal one (the format specifier is %llu, not %llx).

Signed-off-by: Alexandru Elisei <alexandru.elisei@arm.com>
Reviewed-by: Jean-Philippe Brucker <jean-philippe@linaro.org>
Reviewed-by: Anup Patel <anup@brainfault.org>
Link: https://lore.kernel.org/r/20230707151119.81208-3-alexandru.elisei@arm.com
Signed-off-by: Will Deacon <will@kernel.org>

show more ...

kvm-cpu: Pause vCPU in signal handler

Currently, the handling a pause signal only sets a state that will be
checked at the begining of the CPU run loop. At the checking point the vCPU
sends the noti

kvm-cpu: Pause vCPU in signal handler

Currently, the handling a pause signal only sets a state that will be
checked at the begining of the CPU run loop. At the checking point the vCPU
sends the notification that it is actually paused allowing the pause
requester to confirm all vCPUs are paused.

Receiving the pause signal during a KVM_RUN ioctl will make KVM exit to
userspace. However, there is a small window between that check on
cpu->paused and the execution of KVM_RUN where the signal has been received
but the vCPU does not go back through the notification and starts KVM_RUN.
Since there is no guarantee the vCPU will come back to userspace, the
pause requester might deadlock.

Perform the pause directly from the signal handler. This relies on a vCPU
thread never receiving a pause signal while being pause, but such scenario
would have caused a deadlock for the pause requester anyway.

Signed-off-by: Julien Thierry <julien.thierry@arm.com>
Signed-off-by: Will Deacon <will.deacon@arm.com>

show more ...

kvm: Do not pause already paused vcpus

With the following sequence:
kvm__pause();
kvm__continue();
kvm__pause();

There is a chance that not all paused threads have been resumed, and the
second k

kvm: Do not pause already paused vcpus

With the following sequence:
kvm__pause();
kvm__continue();
kvm__pause();

There is a chance that not all paused threads have been resumed, and the
second kvm__pause will attempt to pause them again. Since the paused thread
is waiting to own the pause_lock, it won't write its second pause
notification. kvm__pause will be waiting for that notification while owning
pause_lock, so... deadlock.

Simple solution is not to try to pause thread that had not the chance to
resume.

Signed-off-by: Julien Thierry <julien.thierry@arm.com>
Signed-off-by: Will Deacon <will.deacon@arm.com>

show more ...

kvmtool: delegate exit/reboot responsibility to vcpu0

Our exit/reboot code is a bit of a mess:

- Both kvm__reboot and kvm_cpu_exit send SIGKVMEXIT to running vcpus
- When vcpu0 exits, the main

kvmtool: delegate exit/reboot responsibility to vcpu0

Our exit/reboot code is a bit of a mess:

- Both kvm__reboot and kvm_cpu_exit send SIGKVMEXIT to running vcpus
- When vcpu0 exits, the main thread starts executing destructors
(exitcalls) whilst other vcpus may be running
- The pause_lock isn't always held when inspecting is_running for
a vcpu

This patch attempts to fix these issues by restricting the exit/reboot
path to vcpu0 and the main thread. In particular, a KVM_SYSTEM_EVENT
will signal SIGKVMEXIT to vcpu0, which will join with the main thread
and then tear down the other vcpus before invoking any destructor code.

Acked-by: Balbir Singh <bsingharora@gmail.com>
Tested-by: Julien Grall <julien.grall@arm.com>
Signed-off-by: Will Deacon <will.deacon@arm.com>

show more ...

Add basic infrastructure to run tasks on vCPUs

This patch adds kvm_cpu__run_on_all_cpus() to run a task on each vCPU.
This infrastructure uses signals to signal the vCPU to allow a task
to be added

Add basic infrastructure to run tasks on vCPUs

This patch adds kvm_cpu__run_on_all_cpus() to run a task on each vCPU.
This infrastructure uses signals to signal the vCPU to allow a task
to be added to each vCPU's task. The vCPU executes any pending tasks
in the cpu run loop

Signed-off-by: Balbir Singh <bsingharora@gmail.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Signed-off-by: Will Deacon <will.deacon@arm.com>

show more ...

kvmtool: fix VM exit race attempting to pthread_kill an exited thread

lkvm currently suffers from a Segmentation Fault when exiting, which can
also lead to the console not being cleaned up correctly

kvmtool: fix VM exit race attempting to pthread_kill an exited thread

lkvm currently suffers from a Segmentation Fault when exiting, which can
also lead to the console not being cleaned up correctly after a VM exits.

The issue is that (the misnamed) kvm_cpu__reboot function sends a
SIGKVMEXIT to each vcpu thread, which causes those vcpu threads to exit
once their main loops (kvm_cpu__start) detect that cpu->is_running is
now false. The lack of synchronisation in this exit path means that a
concurrent pause event (due to the br_write_lock in ioport__unregister)
ends up sending SIGKVMPAUSE to an exited thread, resulting in a SEGV.

This patch fixes the issue by moving kvm_cpu__reboot into kvm.c
(renaming it in the process) where it can hold the pause_lock mutex
across the reboot operation. This in turn makes it safe for the pause
code to check the is_running field of each CPU before attempting to
send a SIGKVMPAUSE signal.

Signed-off-by: Will Deacon <will.deacon@arm.com>

show more ...

kvmtool: correct order of the vcpu destructor

The vcpu module is a core component which should be removed last, but the
destructor was mistakenly marked as something that should be done first.

This

kvmtool: correct order of the vcpu destructor

The vcpu module is a core component which should be removed last, but the
destructor was mistakenly marked as something that should be done first.

This would cause the vcpu data to be freed up before anything else had the
chance to exit, and assuming that that data was still valid - causing use
after frees.

Reported-by: Dmitry Vyukov <dvyukov@google.com>
Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
Signed-off-by: Will Deacon <will.deacon@arm.com>

show more ...

Handle KVM_EXIT_SYSTEM_EVENT on any VCPU

When VCPU #0 exits (e.g. due to KVM_EXIT_SYSTEM_EVENT), it sends
SIGKVMEXIT to all other VCPUs, waits for them to exit, then tears down
any remaining context

Handle KVM_EXIT_SYSTEM_EVENT on any VCPU

When VCPU #0 exits (e.g. due to KVM_EXIT_SYSTEM_EVENT), it sends
SIGKVMEXIT to all other VCPUs, waits for them to exit, then tears down
any remaining context. The signalling of SIGKVMEXIT is critical to
forcing VCPUs to shut down in response to a system event (e.g. PSCI
SYSTEM_OFF).

VCPUs other that VCPU #0 simply exit in kvm_cpu_thread without forcing
other CPUs to shut down. Thus if a system event is taken on a VCPU other
than VCPU #0, the remaining CPUs are left online. This results in KVM
tool not exiting as expected when a system event is taken on a VCPU
other than VCPU #0 (as may happen if the guest panics).

Fix this by tearing down all CPUs upon a system event, regardless of the
CPU on which the event occurred. While this means the VCPU thread will
signal itself, and VCPU #0 will signal all other VCPU threads a second
time, these are harmless.

Signed-off-by: Mark Rutland <mark.rutland@arm.com>
Cc: Marc Zyngier <marc.zyngier@arm.com>
Cc: Suzuki Poulose <suzuki.poulose@arm.com>
Cc: Will Deacon <will.deacon@arm.com>
Signed-off-by: Will Deacon <will.deacon@arm.com>

show more ...

kvmtool: Handle exit reason KVM_EXIT_SYSTEM_EVENT

The KVM_EXIT_SYSTEM_EVENT exit reason was added to define
architecture independent system-wide events for a Guest.

Currently, it is used by in-kern

kvmtool: Handle exit reason KVM_EXIT_SYSTEM_EVENT

The KVM_EXIT_SYSTEM_EVENT exit reason was added to define
architecture independent system-wide events for a Guest.

Currently, it is used by in-kernel PSCI-0.2 emulation of
KVM ARM/ARM64 to inform user space about PSCI SYSTEM_OFF
or PSCI SYSTEM_RESET request.

For now, we simply treat all system-wide guest events as
shutdown request in KVMTOOL.

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>
[will: removed useless prints]
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: sample CPU endianness on virtio-mmio device reset

Save the CPU endianness when the device is reset. It is widely
assumed that the guest won't change its endianness after, or at
least not wi

kvmtool: sample CPU endianness on virtio-mmio device reset

Save the CPU endianness when the device is reset. It is widely
assumed that the guest won't change its endianness after, or at
least not without reseting the device first.

A default implementation of the endianness sampling just returns
the default "host endianness" value so that unsuspecting architectures
are not affected.

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: remove global kvm object

This was ugly, and now we get rid of it.

Signed-off-by: Sasha Levin <levinsasha928@gmail.com>
Signed-off-by: Pekka Enberg <penberg@kernel.org>

kvm tools: use init/exit where possible

Switch to using init/exit calls instead of the repeating call blocks in builtin-run.

Signed-off-by: Sasha Levin <levinsasha928@gmail.com>
Signed-off-by: Pekk

kvm tools: use init/exit where possible

Switch to using init/exit calls instead of the repeating call blocks in builtin-run.

Signed-off-by: Sasha Levin <levinsasha928@gmail.com>
Signed-off-by: Pekka Enberg <penberg@kernel.org>

show more ...

kvm tools: move kvm_cpus into struct kvm

There's no reason the array of guest specific vcpus is global. Move it into
struct kvm.

Also split up arch specific vcpu init from the generic code and call

kvm tools: move kvm_cpus into struct kvm

There's no reason the array of guest specific vcpus is global. Move it into
struct kvm.

Also split up arch specific vcpu init from the generic code and call it from
the kvm_cpu initializer.

Signed-off-by: Sasha Levin <levinsasha928@gmail.com>
Signed-off-by: Pekka Enberg <penberg@kernel.org>

show more ...

kvm tools: remove redundancy between kvm_config and kvm

Remove some redundant members between struct kvm_config and struct kvm
since options are now contained within struct kvm.

Signed-off-by: Sash

kvm tools: remove redundancy between kvm_config and kvm

Remove some redundant members between struct kvm_config and struct kvm
since options are now contained within struct kvm.

Signed-off-by: Sasha Levin <levinsasha928@gmail.com>
Signed-off-by: Pekka Enberg <penberg@kernel.org>

show more ...

kvm tools: Do not run guest if it is stopped.

If the guest is stopped, there is no need to run it.
This patch fixes this when running 'lkvm stop'.

KVM_RUN failed: Bad address

Signed-off-by: Asi

kvm tools: Do not run guest if it is stopped.

If the guest is stopped, there is no need to run it.
This patch fixes this when running 'lkvm stop'.

KVM_RUN failed: Bad address

Signed-off-by: Asias He <asias.hejun@gmail.com>
Signed-off-by: Pekka Enberg <penberg@kernel.org>

show more ...

kvm tools: Fix 'lkvm stop' when guest is pasued.

Currently, 'lkvm stop' can not stop a pasued guest becasue
guest is blocked on the pause_lock.

This patch fixes it by un-pausing the guest before st

kvm tools: Fix 'lkvm stop' when guest is pasued.

Currently, 'lkvm stop' can not stop a pasued guest becasue
guest is blocked on the pause_lock.

This patch fixes it by un-pausing the guest before stops it.

The pthread_kill() call is not needed.

Signed-off-by: Asias He <asias.hejun@gmail.com>
Signed-off-by: Pekka Enberg <penberg@kernel.org>

show more ...

kvm tools: Remove KVM_NR_CPUS

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 th

kvm tools: Remove KVM_NR_CPUS

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>

show more ...

kvm tools: Fix MMIO ordering problem cause due to coalescing

If we took a MMIO exit, the data in the coalesced ring should be processes
before the data in the exit itself is processed.

Doing it wro

kvm tools: Fix MMIO ordering problem cause due to coalescing

If we took a MMIO exit, the data in the coalesced ring should be processes
before the data in the exit itself is processed.

Doing it wrong (like we did so far) will cause ordering issues.

Signed-off-by: Sasha Levin <levinsasha928@gmail.com>
Signed-off-by: Pekka Enberg <penberg@kernel.org>

show more ...

kvm tools: Create arch-specific kvm_cpu__emulate_{mm}io()

Different architectures will deal with MMIO exits differently. For example,
KVM_EXIT_IO is x86-specific, and I/O cycles are often synthesis

kvm tools: Create arch-specific kvm_cpu__emulate_{mm}io()

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>

show more ...

kvm tools: Add NMI ability to 'kvm debug'

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 m

kvm tools: Add NMI ability to 'kvm debug'

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>

show more ...

kvm tools: Fix KVM_RUN exit code check

kvm_cpu__run() currently die()s if KVM_RUN returns non-zero. Some architectures
may return positive values in non-error cases, whereas real errors are always

kvm tools: Fix KVM_RUN exit code check

kvm_cpu__run() currently die()s if KVM_RUN returns non-zero. Some architectures
may return positive values in non-error cases, whereas real errors are always
negative return values. Check for those instead.

Signed-off-by: Matt Evans <matt@ozlabs.org>
Signed-off-by: Pekka Enberg <penberg@kernel.org>

show more ...

kvm tools: Add arch-specific KVM_RUN exit handling via kvm_cpu__handle_exit()

This patch creates a new function in x86/kvm-cpu.c, kvm_cpu__handle_exit(), in
which arch-specific exit reasons can be h

kvm tools: Add arch-specific KVM_RUN exit handling via kvm_cpu__handle_exit()

This patch creates a new function in x86/kvm-cpu.c, kvm_cpu__handle_exit(), in
which arch-specific exit reasons can be handled outside of the common runloop.

Signed-off-by: Matt Evans <matt@ozlabs.org>
Signed-off-by: Pekka Enberg <penberg@kernel.org>

show more ...

kvm tools: Split x86 arch-specific bits into x86/

Create a new arch-specific subdirectory to contain architecture-specific code
and includes.

The Makefile now adds various arch-specific objects bas

kvm tools: Split x86 arch-specific bits into x86/

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>

show more ...