2019-05-29 22:12:40 +08:00
|
|
|
// SPDX-License-Identifier: GPL-2.0-only
|
2013-01-21 07:28:06 +08:00
|
|
|
/*
|
|
|
|
* Copyright (C) 2012 - Virtual Open Systems and Columbia University
|
|
|
|
* Author: Christoffer Dall <c.dall@virtualopensystems.com>
|
|
|
|
*/
|
|
|
|
|
2018-04-20 23:20:43 +08:00
|
|
|
#include <linux/bug.h>
|
2013-08-05 22:04:46 +08:00
|
|
|
#include <linux/cpu_pm.h>
|
2021-08-03 03:28:09 +08:00
|
|
|
#include <linux/entry-kvm.h>
|
2013-01-21 07:28:06 +08:00
|
|
|
#include <linux/errno.h>
|
|
|
|
#include <linux/err.h>
|
|
|
|
#include <linux/kvm_host.h>
|
2016-07-15 19:43:31 +08:00
|
|
|
#include <linux/list.h>
|
2013-01-21 07:28:06 +08:00
|
|
|
#include <linux/module.h>
|
|
|
|
#include <linux/vmalloc.h>
|
|
|
|
#include <linux/fs.h>
|
|
|
|
#include <linux/mman.h>
|
|
|
|
#include <linux/sched.h>
|
2021-08-02 20:38:30 +08:00
|
|
|
#include <linux/kmemleak.h>
|
2013-01-21 07:28:08 +08:00
|
|
|
#include <linux/kvm.h>
|
2017-10-27 22:28:31 +08:00
|
|
|
#include <linux/kvm_irqfd.h>
|
|
|
|
#include <linux/irqbypass.h>
|
2018-06-21 17:43:59 +08:00
|
|
|
#include <linux/sched/stat.h>
|
2020-12-03 02:41:12 +08:00
|
|
|
#include <linux/psci.h>
|
2013-01-21 07:28:06 +08:00
|
|
|
#include <trace/events/kvm.h>
|
|
|
|
|
|
|
|
#define CREATE_TRACE_POINTS
|
2020-05-13 18:40:34 +08:00
|
|
|
#include "trace_arm.h"
|
2013-01-21 07:28:06 +08:00
|
|
|
|
2016-12-25 03:46:01 +08:00
|
|
|
#include <linux/uaccess.h>
|
2013-01-21 07:28:06 +08:00
|
|
|
#include <asm/ptrace.h>
|
|
|
|
#include <asm/mman.h>
|
2013-01-21 07:28:06 +08:00
|
|
|
#include <asm/tlbflush.h>
|
2013-01-21 07:28:09 +08:00
|
|
|
#include <asm/cacheflush.h>
|
2018-04-20 23:20:43 +08:00
|
|
|
#include <asm/cpufeature.h>
|
2013-01-21 07:28:06 +08:00
|
|
|
#include <asm/virt.h>
|
|
|
|
#include <asm/kvm_arm.h>
|
|
|
|
#include <asm/kvm_asm.h>
|
|
|
|
#include <asm/kvm_mmu.h>
|
KVM: ARM: World-switch implementation
Provides complete world-switch implementation to switch to other guests
running in non-secure modes. Includes Hyp exception handlers that
capture necessary exception information and stores the information on
the VCPU and KVM structures.
The following Hyp-ABI is also documented in the code:
Hyp-ABI: Calling HYP-mode functions from host (in SVC mode):
Switching to Hyp mode is done through a simple HVC #0 instruction. The
exception vector code will check that the HVC comes from VMID==0 and if
so will push the necessary state (SPSR, lr_usr) on the Hyp stack.
- r0 contains a pointer to a HYP function
- r1, r2, and r3 contain arguments to the above function.
- The HYP function will be called with its arguments in r0, r1 and r2.
On HYP function return, we return directly to SVC.
A call to a function executing in Hyp mode is performed like the following:
<svc code>
ldr r0, =BSYM(my_hyp_fn)
ldr r1, =my_param
hvc #0 ; Call my_hyp_fn(my_param) from HYP mode
<svc code>
Otherwise, the world-switch is pretty straight-forward. All state that
can be modified by the guest is first backed up on the Hyp stack and the
VCPU values is loaded onto the hardware. State, which is not loaded, but
theoretically modifiable by the guest is protected through the
virtualiation features to generate a trap and cause software emulation.
Upon guest returns, all state is restored from hardware onto the VCPU
struct and the original state is restored from the Hyp-stack onto the
hardware.
SMP support using the VMPIDR calculated on the basis of the host MPIDR
and overriding the low bits with KVM vcpu_id contributed by Marc Zyngier.
Reuse of VMIDs has been implemented by Antonios Motakis and adapated from
a separate patch into the appropriate patches introducing the
functionality. Note that the VMIDs are stored per VM as required by the ARM
architecture reference manual.
To support VFP/NEON we trap those instructions using the HPCTR. When
we trap, we switch the FPU. After a guest exit, the VFP state is
returned to the host. When disabling access to floating point
instructions, we also mask FPEXC_EN in order to avoid the guest
receiving Undefined instruction exceptions before we have a chance to
switch back the floating point state. We are reusing vfp_hard_struct,
so we depend on VFPv3 being enabled in the host kernel, if not, we still
trap cp10 and cp11 in order to inject an undefined instruction exception
whenever the guest tries to use VFP/NEON. VFP/NEON developed by
Antionios Motakis and Rusty Russell.
Aborts that are permission faults, and not stage-1 page table walk, do
not report the faulting address in the HPFAR. We have to resolve the
IPA, and store it just like the HPFAR register on the VCPU struct. If
the IPA cannot be resolved, it means another CPU is playing with the
page tables, and we simply restart the guest. This quirk was fixed by
Marc Zyngier.
Reviewed-by: Will Deacon <will.deacon@arm.com>
Reviewed-by: Marcelo Tosatti <mtosatti@redhat.com>
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Signed-off-by: Antonios Motakis <a.motakis@virtualopensystems.com>
Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
Signed-off-by: Christoffer Dall <c.dall@virtualopensystems.com>
2013-01-21 07:47:42 +08:00
|
|
|
#include <asm/kvm_emulate.h>
|
2015-10-27 20:18:48 +08:00
|
|
|
#include <asm/sections.h>
|
2013-01-21 07:28:06 +08:00
|
|
|
|
2019-10-21 23:28:18 +08:00
|
|
|
#include <kvm/arm_hypercalls.h>
|
|
|
|
#include <kvm/arm_pmu.h>
|
|
|
|
#include <kvm/arm_psci.h>
|
|
|
|
|
2020-12-03 02:40:57 +08:00
|
|
|
static enum kvm_mode kvm_mode = KVM_MODE_DEFAULT;
|
2020-12-03 02:41:22 +08:00
|
|
|
DEFINE_STATIC_KEY_FALSE(kvm_protected_mode_initialized);
|
2020-12-03 02:40:57 +08:00
|
|
|
|
2020-09-30 21:05:35 +08:00
|
|
|
DECLARE_KVM_HYP_PER_CPU(unsigned long, kvm_hyp_vector);
|
|
|
|
|
2013-01-21 07:28:06 +08:00
|
|
|
static DEFINE_PER_CPU(unsigned long, kvm_arm_hyp_stack_page);
|
2020-09-23 04:49:09 +08:00
|
|
|
unsigned long kvm_arm_hyp_percpu_base[NR_CPUS];
|
2020-12-03 02:41:06 +08:00
|
|
|
DECLARE_KVM_NVHE_PER_CPU(struct kvm_nvhe_init_params, kvm_init_params);
|
2013-01-21 07:28:06 +08:00
|
|
|
|
2015-12-18 19:38:43 +08:00
|
|
|
static bool vgic_present;
|
|
|
|
|
arm64: kvm: allows kvm cpu hotplug
The current kvm implementation on arm64 does cpu-specific initialization
at system boot, and has no way to gracefully shutdown a core in terms of
kvm. This prevents kexec from rebooting the system at EL2.
This patch adds a cpu tear-down function and also puts an existing cpu-init
code into a separate function, kvm_arch_hardware_disable() and
kvm_arch_hardware_enable() respectively.
We don't need the arm64 specific cpu hotplug hook any more.
Since this patch modifies common code between arm and arm64, one stub
definition, __cpu_reset_hyp_mode(), is added on arm side to avoid
compilation errors.
Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
[Rebase, added separate VHE init/exit path, changed resets use of
kvm_call_hyp() to the __version, en/disabled hardware in init_subsystems(),
added icache maintenance to __kvm_hyp_reset() and removed lr restore, removed
guest-enter after teardown handling]
Signed-off-by: James Morse <james.morse@arm.com>
Acked-by: Marc Zyngier <marc.zyngier@arm.com>
Signed-off-by: Will Deacon <will.deacon@arm.com>
2016-04-28 00:47:05 +08:00
|
|
|
static DEFINE_PER_CPU(unsigned char, kvm_arm_hardware_enabled);
|
2017-10-28 01:57:51 +08:00
|
|
|
DEFINE_STATIC_KEY_FALSE(userspace_irqchip_in_use);
|
|
|
|
|
2013-01-21 07:28:06 +08:00
|
|
|
int kvm_arch_vcpu_should_kick(struct kvm_vcpu *vcpu)
|
|
|
|
{
|
|
|
|
return kvm_vcpu_exiting_guest_mode(vcpu) == IN_GUEST_MODE;
|
|
|
|
}
|
|
|
|
|
2020-03-22 04:25:55 +08:00
|
|
|
int kvm_arch_hardware_setup(void *opaque)
|
2013-01-21 07:28:06 +08:00
|
|
|
{
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2020-03-22 04:25:55 +08:00
|
|
|
int kvm_arch_check_processor_compat(void *opaque)
|
2013-01-21 07:28:06 +08:00
|
|
|
{
|
2019-04-20 13:18:17 +08:00
|
|
|
return 0;
|
2013-01-21 07:28:06 +08:00
|
|
|
}
|
|
|
|
|
KVM: arm/arm64: Allow reporting non-ISV data aborts to userspace
For a long time, if a guest accessed memory outside of a memslot using
any of the load/store instructions in the architecture which doesn't
supply decoding information in the ESR_EL2 (the ISV bit is not set), the
kernel would print the following message and terminate the VM as a
result of returning -ENOSYS to userspace:
load/store instruction decoding not implemented
The reason behind this message is that KVM assumes that all accesses
outside a memslot is an MMIO access which should be handled by
userspace, and we originally expected to eventually implement some sort
of decoding of load/store instructions where the ISV bit was not set.
However, it turns out that many of the instructions which don't provide
decoding information on abort are not safe to use for MMIO accesses, and
the remaining few that would potentially make sense to use on MMIO
accesses, such as those with register writeback, are not used in
practice. It also turns out that fetching an instruction from guest
memory can be a pretty horrible affair, involving stopping all CPUs on
SMP systems, handling multiple corner cases of address translation in
software, and more. It doesn't appear likely that we'll ever implement
this in the kernel.
What is much more common is that a user has misconfigured his/her guest
and is actually not accessing an MMIO region, but just hitting some
random hole in the IPA space. In this scenario, the error message above
is almost misleading and has led to a great deal of confusion over the
years.
It is, nevertheless, ABI to userspace, and we therefore need to
introduce a new capability that userspace explicitly enables to change
behavior.
This patch introduces KVM_CAP_ARM_NISV_TO_USER (NISV meaning Non-ISV)
which does exactly that, and introduces a new exit reason to report the
event to userspace. User space can then emulate an exception to the
guest, restart the guest, suspend the guest, or take any other
appropriate action as per the policy of the running system.
Reported-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Signed-off-by: Christoffer Dall <christoffer.dall@arm.com>
Reviewed-by: Alexander Graf <graf@amazon.com>
Signed-off-by: Marc Zyngier <maz@kernel.org>
2019-10-11 19:07:05 +08:00
|
|
|
int kvm_vm_ioctl_enable_cap(struct kvm *kvm,
|
|
|
|
struct kvm_enable_cap *cap)
|
|
|
|
{
|
|
|
|
int r;
|
|
|
|
|
|
|
|
if (cap->flags)
|
|
|
|
return -EINVAL;
|
|
|
|
|
|
|
|
switch (cap->cap) {
|
|
|
|
case KVM_CAP_ARM_NISV_TO_USER:
|
|
|
|
r = 0;
|
2022-03-12 01:39:47 +08:00
|
|
|
set_bit(KVM_ARCH_FLAG_RETURN_NISV_IO_ABORT_TO_USER,
|
|
|
|
&kvm->arch.flags);
|
KVM: arm/arm64: Allow reporting non-ISV data aborts to userspace
For a long time, if a guest accessed memory outside of a memslot using
any of the load/store instructions in the architecture which doesn't
supply decoding information in the ESR_EL2 (the ISV bit is not set), the
kernel would print the following message and terminate the VM as a
result of returning -ENOSYS to userspace:
load/store instruction decoding not implemented
The reason behind this message is that KVM assumes that all accesses
outside a memslot is an MMIO access which should be handled by
userspace, and we originally expected to eventually implement some sort
of decoding of load/store instructions where the ISV bit was not set.
However, it turns out that many of the instructions which don't provide
decoding information on abort are not safe to use for MMIO accesses, and
the remaining few that would potentially make sense to use on MMIO
accesses, such as those with register writeback, are not used in
practice. It also turns out that fetching an instruction from guest
memory can be a pretty horrible affair, involving stopping all CPUs on
SMP systems, handling multiple corner cases of address translation in
software, and more. It doesn't appear likely that we'll ever implement
this in the kernel.
What is much more common is that a user has misconfigured his/her guest
and is actually not accessing an MMIO region, but just hitting some
random hole in the IPA space. In this scenario, the error message above
is almost misleading and has led to a great deal of confusion over the
years.
It is, nevertheless, ABI to userspace, and we therefore need to
introduce a new capability that userspace explicitly enables to change
behavior.
This patch introduces KVM_CAP_ARM_NISV_TO_USER (NISV meaning Non-ISV)
which does exactly that, and introduces a new exit reason to report the
event to userspace. User space can then emulate an exception to the
guest, restart the guest, suspend the guest, or take any other
appropriate action as per the policy of the running system.
Reported-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Signed-off-by: Christoffer Dall <christoffer.dall@arm.com>
Reviewed-by: Alexander Graf <graf@amazon.com>
Signed-off-by: Marc Zyngier <maz@kernel.org>
2019-10-11 19:07:05 +08:00
|
|
|
break;
|
2021-06-21 19:17:14 +08:00
|
|
|
case KVM_CAP_ARM_MTE:
|
2021-07-30 00:00:36 +08:00
|
|
|
mutex_lock(&kvm->lock);
|
|
|
|
if (!system_supports_mte() || kvm->created_vcpus) {
|
|
|
|
r = -EINVAL;
|
|
|
|
} else {
|
|
|
|
r = 0;
|
2022-03-12 01:39:47 +08:00
|
|
|
set_bit(KVM_ARCH_FLAG_MTE_ENABLED, &kvm->arch.flags);
|
2021-07-30 00:00:36 +08:00
|
|
|
}
|
|
|
|
mutex_unlock(&kvm->lock);
|
2021-06-21 19:17:14 +08:00
|
|
|
break;
|
2022-05-04 11:24:41 +08:00
|
|
|
case KVM_CAP_ARM_SYSTEM_SUSPEND:
|
|
|
|
r = 0;
|
|
|
|
set_bit(KVM_ARCH_FLAG_SYSTEM_SUSPEND_ENABLED, &kvm->arch.flags);
|
|
|
|
break;
|
KVM: arm/arm64: Allow reporting non-ISV data aborts to userspace
For a long time, if a guest accessed memory outside of a memslot using
any of the load/store instructions in the architecture which doesn't
supply decoding information in the ESR_EL2 (the ISV bit is not set), the
kernel would print the following message and terminate the VM as a
result of returning -ENOSYS to userspace:
load/store instruction decoding not implemented
The reason behind this message is that KVM assumes that all accesses
outside a memslot is an MMIO access which should be handled by
userspace, and we originally expected to eventually implement some sort
of decoding of load/store instructions where the ISV bit was not set.
However, it turns out that many of the instructions which don't provide
decoding information on abort are not safe to use for MMIO accesses, and
the remaining few that would potentially make sense to use on MMIO
accesses, such as those with register writeback, are not used in
practice. It also turns out that fetching an instruction from guest
memory can be a pretty horrible affair, involving stopping all CPUs on
SMP systems, handling multiple corner cases of address translation in
software, and more. It doesn't appear likely that we'll ever implement
this in the kernel.
What is much more common is that a user has misconfigured his/her guest
and is actually not accessing an MMIO region, but just hitting some
random hole in the IPA space. In this scenario, the error message above
is almost misleading and has led to a great deal of confusion over the
years.
It is, nevertheless, ABI to userspace, and we therefore need to
introduce a new capability that userspace explicitly enables to change
behavior.
This patch introduces KVM_CAP_ARM_NISV_TO_USER (NISV meaning Non-ISV)
which does exactly that, and introduces a new exit reason to report the
event to userspace. User space can then emulate an exception to the
guest, restart the guest, suspend the guest, or take any other
appropriate action as per the policy of the running system.
Reported-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Signed-off-by: Christoffer Dall <christoffer.dall@arm.com>
Reviewed-by: Alexander Graf <graf@amazon.com>
Signed-off-by: Marc Zyngier <maz@kernel.org>
2019-10-11 19:07:05 +08:00
|
|
|
default:
|
|
|
|
r = -EINVAL;
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
|
|
|
|
return r;
|
|
|
|
}
|
2013-01-21 07:28:06 +08:00
|
|
|
|
2020-04-27 22:15:07 +08:00
|
|
|
static int kvm_arm_default_max_vcpus(void)
|
|
|
|
{
|
|
|
|
return vgic_present ? kvm_vgic_get_max_vcpus() : KVM_MAX_VCPUS;
|
|
|
|
}
|
|
|
|
|
2020-11-27 01:27:13 +08:00
|
|
|
static void set_default_spectre(struct kvm *kvm)
|
2020-11-10 22:13:06 +08:00
|
|
|
{
|
|
|
|
/*
|
|
|
|
* The default is to expose CSV2 == 1 if the HW isn't affected.
|
|
|
|
* Although this is a per-CPU feature, we make it global because
|
|
|
|
* asymmetric systems are just a nuisance.
|
|
|
|
*
|
|
|
|
* Userspace can override this as long as it doesn't promise
|
|
|
|
* the impossible.
|
|
|
|
*/
|
|
|
|
if (arm64_get_spectre_v2_state() == SPECTRE_UNAFFECTED)
|
|
|
|
kvm->arch.pfr0_csv2 = 1;
|
2020-11-27 01:27:13 +08:00
|
|
|
if (arm64_get_meltdown_state() == SPECTRE_UNAFFECTED)
|
|
|
|
kvm->arch.pfr0_csv3 = 1;
|
2020-11-10 22:13:06 +08:00
|
|
|
}
|
|
|
|
|
2013-01-21 07:28:07 +08:00
|
|
|
/**
|
|
|
|
* kvm_arch_init_vm - initializes a VM data structure
|
|
|
|
* @kvm: pointer to the KVM struct
|
|
|
|
*/
|
2013-01-21 07:28:06 +08:00
|
|
|
int kvm_arch_init_vm(struct kvm *kvm, unsigned long type)
|
|
|
|
{
|
2019-01-05 04:09:05 +08:00
|
|
|
int ret;
|
2013-01-21 07:28:07 +08:00
|
|
|
|
2018-10-01 20:40:36 +08:00
|
|
|
ret = kvm_arm_setup_stage2(kvm, type);
|
2018-09-27 00:32:42 +08:00
|
|
|
if (ret)
|
|
|
|
return ret;
|
2013-01-21 07:28:06 +08:00
|
|
|
|
2019-01-05 04:09:05 +08:00
|
|
|
ret = kvm_init_stage2_mmu(kvm, &kvm->arch.mmu);
|
2013-01-21 07:28:07 +08:00
|
|
|
if (ret)
|
2019-01-05 04:09:05 +08:00
|
|
|
return ret;
|
2013-01-21 07:28:07 +08:00
|
|
|
|
2021-12-16 00:12:23 +08:00
|
|
|
ret = kvm_share_hyp(kvm, kvm + 1);
|
2013-01-21 07:28:07 +08:00
|
|
|
if (ret)
|
|
|
|
goto out_free_stage2_pgd;
|
|
|
|
|
2022-01-28 00:17:59 +08:00
|
|
|
if (!zalloc_cpumask_var(&kvm->arch.supported_cpus, GFP_KERNEL))
|
|
|
|
goto out_free_stage2_pgd;
|
|
|
|
cpumask_copy(kvm->arch.supported_cpus, cpu_possible_mask);
|
|
|
|
|
2014-06-24 00:37:18 +08:00
|
|
|
kvm_vgic_early_init(kvm);
|
2013-11-17 02:51:25 +08:00
|
|
|
|
2014-06-02 22:26:01 +08:00
|
|
|
/* The maximum number of VCPUs is limited by the host's GIC model */
|
2022-03-05 03:48:38 +08:00
|
|
|
kvm->max_vcpus = kvm_arm_default_max_vcpus();
|
2014-06-02 22:26:01 +08:00
|
|
|
|
2020-11-27 01:27:13 +08:00
|
|
|
set_default_spectre(kvm);
|
KVM: arm64: Setup a framework for hypercall bitmap firmware registers
KVM regularly introduces new hypercall services to the guests without
any consent from the userspace. This means, the guests can observe
hypercall services in and out as they migrate across various host
kernel versions. This could be a major problem if the guest
discovered a hypercall, started using it, and after getting migrated
to an older kernel realizes that it's no longer available. Depending
on how the guest handles the change, there's a potential chance that
the guest would just panic.
As a result, there's a need for the userspace to elect the services
that it wishes the guest to discover. It can elect these services
based on the kernels spread across its (migration) fleet. To remedy
this, extend the existing firmware pseudo-registers, such as
KVM_REG_ARM_PSCI_VERSION, but by creating a new COPROC register space
for all the hypercall services available.
These firmware registers are categorized based on the service call
owners, but unlike the existing firmware pseudo-registers, they hold
the features supported in the form of a bitmap.
During the VM initialization, the registers are set to upper-limit of
the features supported by the corresponding registers. It's expected
that the VMMs discover the features provided by each register via
GET_ONE_REG, and write back the desired values using SET_ONE_REG.
KVM allows this modification only until the VM has started.
Some of the standard features are not mapped to any bits of the
registers. But since they can recreate the original problem of
making it available without userspace's consent, they need to
be explicitly added to the case-list in
kvm_hvc_call_default_allowed(). Any function-id that's not enabled
via the bitmap, or not listed in kvm_hvc_call_default_allowed, will
be returned as SMCCC_RET_NOT_SUPPORTED to the guest.
Older userspace code can simply ignore the feature and the
hypercall services will be exposed unconditionally to the guests,
thus ensuring backward compatibility.
In this patch, the framework adds the register only for ARM's standard
secure services (owner value 4). Currently, this includes support only
for ARM True Random Number Generator (TRNG) service, with bit-0 of the
register representing mandatory features of v1.0. Other services are
momentarily added in the upcoming patches.
Signed-off-by: Raghavendra Rao Ananta <rananta@google.com>
Reviewed-by: Gavin Shan <gshan@redhat.com>
[maz: reduced the scope of some helpers, tidy-up bitmap max values,
dropped error-only fast path]
Signed-off-by: Marc Zyngier <maz@kernel.org>
Link: https://lore.kernel.org/r/20220502233853.1233742-3-rananta@google.com
2022-05-03 07:38:46 +08:00
|
|
|
kvm_arm_init_hypercalls(kvm);
|
2020-11-10 22:13:06 +08:00
|
|
|
|
2013-01-21 07:28:07 +08:00
|
|
|
return ret;
|
|
|
|
out_free_stage2_pgd:
|
2019-01-05 04:09:05 +08:00
|
|
|
kvm_free_stage2_pgd(&kvm->arch.mmu);
|
2013-01-21 07:28:07 +08:00
|
|
|
return ret;
|
2013-01-21 07:28:06 +08:00
|
|
|
}
|
|
|
|
|
2018-04-19 03:19:58 +08:00
|
|
|
vm_fault_t kvm_arch_vcpu_fault(struct kvm_vcpu *vcpu, struct vm_fault *vmf)
|
2013-01-21 07:28:06 +08:00
|
|
|
{
|
|
|
|
return VM_FAULT_SIGBUS;
|
|
|
|
}
|
|
|
|
|
|
|
|
|
2013-01-21 07:28:07 +08:00
|
|
|
/**
|
|
|
|
* kvm_arch_destroy_vm - destroy the VM data structure
|
|
|
|
* @kvm: pointer to the KVM struct
|
|
|
|
*/
|
2013-01-21 07:28:06 +08:00
|
|
|
void kvm_arch_destroy_vm(struct kvm *kvm)
|
|
|
|
{
|
2020-02-12 19:31:02 +08:00
|
|
|
bitmap_free(kvm->arch.pmu_filter);
|
2022-01-28 00:17:59 +08:00
|
|
|
free_cpumask_var(kvm->arch.supported_cpus);
|
2020-02-12 19:31:02 +08:00
|
|
|
|
2017-10-27 22:28:34 +08:00
|
|
|
kvm_vgic_destroy(kvm);
|
|
|
|
|
2021-11-17 00:03:57 +08:00
|
|
|
kvm_destroy_vcpus(kvm);
|
2021-12-16 00:12:31 +08:00
|
|
|
|
|
|
|
kvm_unshare_hyp(kvm, kvm + 1);
|
2013-01-21 07:28:06 +08:00
|
|
|
}
|
|
|
|
|
2014-07-15 00:27:35 +08:00
|
|
|
int kvm_vm_ioctl_check_extension(struct kvm *kvm, long ext)
|
2013-01-21 07:28:06 +08:00
|
|
|
{
|
|
|
|
int r;
|
|
|
|
switch (ext) {
|
2013-01-22 08:36:12 +08:00
|
|
|
case KVM_CAP_IRQCHIP:
|
2015-12-18 19:38:43 +08:00
|
|
|
r = vgic_present;
|
|
|
|
break;
|
2015-01-24 20:00:02 +08:00
|
|
|
case KVM_CAP_IOEVENTFD:
|
2013-10-26 00:29:18 +08:00
|
|
|
case KVM_CAP_DEVICE_CTRL:
|
2013-01-21 07:28:06 +08:00
|
|
|
case KVM_CAP_USER_MEMORY:
|
|
|
|
case KVM_CAP_SYNC_MMU:
|
|
|
|
case KVM_CAP_DESTROY_MEMORY_REGION_WORKS:
|
|
|
|
case KVM_CAP_ONE_REG:
|
2013-01-21 07:28:13 +08:00
|
|
|
case KVM_CAP_ARM_PSCI:
|
2014-04-29 13:54:25 +08:00
|
|
|
case KVM_CAP_ARM_PSCI_0_2:
|
2014-08-19 18:18:04 +08:00
|
|
|
case KVM_CAP_READONLY_MEM:
|
2015-03-14 01:02:52 +08:00
|
|
|
case KVM_CAP_MP_STATE:
|
2017-02-08 18:50:15 +08:00
|
|
|
case KVM_CAP_IMMEDIATE_EXIT:
|
2018-10-13 00:12:49 +08:00
|
|
|
case KVM_CAP_VCPU_EVENTS:
|
KVM: arm/arm64: vgic: Allow more than 256 vcpus for KVM_IRQ_LINE
While parts of the VGIC support a large number of vcpus (we
bravely allow up to 512), other parts are more limited.
One of these limits is visible in the KVM_IRQ_LINE ioctl, which
only allows 256 vcpus to be signalled when using the CPU or PPI
types. Unfortunately, we've cornered ourselves badly by allocating
all the bits in the irq field.
Since the irq_type subfield (8 bit wide) is currently only taking
the values 0, 1 and 2 (and we have been careful not to allow anything
else), let's reduce this field to only 4 bits, and allocate the
remaining 4 bits to a vcpu2_index, which acts as a multiplier:
vcpu_id = 256 * vcpu2_index + vcpu_index
With that, and a new capability (KVM_CAP_ARM_IRQ_LINE_LAYOUT_2)
allowing this to be discovered, it becomes possible to inject
PPIs to up to 4096 vcpus. But please just don't.
Whilst we're there, add a clarification about the use of KVM_IRQ_LINE
on arm, which is not completely conditionned by KVM_CAP_IRQCHIP.
Reported-by: Zenghui Yu <yuzenghui@huawei.com>
Reviewed-by: Eric Auger <eric.auger@redhat.com>
Reviewed-by: Zenghui Yu <yuzenghui@huawei.com>
Signed-off-by: Marc Zyngier <maz@kernel.org>
2019-08-18 21:09:47 +08:00
|
|
|
case KVM_CAP_ARM_IRQ_LINE_LAYOUT_2:
|
KVM: arm/arm64: Allow reporting non-ISV data aborts to userspace
For a long time, if a guest accessed memory outside of a memslot using
any of the load/store instructions in the architecture which doesn't
supply decoding information in the ESR_EL2 (the ISV bit is not set), the
kernel would print the following message and terminate the VM as a
result of returning -ENOSYS to userspace:
load/store instruction decoding not implemented
The reason behind this message is that KVM assumes that all accesses
outside a memslot is an MMIO access which should be handled by
userspace, and we originally expected to eventually implement some sort
of decoding of load/store instructions where the ISV bit was not set.
However, it turns out that many of the instructions which don't provide
decoding information on abort are not safe to use for MMIO accesses, and
the remaining few that would potentially make sense to use on MMIO
accesses, such as those with register writeback, are not used in
practice. It also turns out that fetching an instruction from guest
memory can be a pretty horrible affair, involving stopping all CPUs on
SMP systems, handling multiple corner cases of address translation in
software, and more. It doesn't appear likely that we'll ever implement
this in the kernel.
What is much more common is that a user has misconfigured his/her guest
and is actually not accessing an MMIO region, but just hitting some
random hole in the IPA space. In this scenario, the error message above
is almost misleading and has led to a great deal of confusion over the
years.
It is, nevertheless, ABI to userspace, and we therefore need to
introduce a new capability that userspace explicitly enables to change
behavior.
This patch introduces KVM_CAP_ARM_NISV_TO_USER (NISV meaning Non-ISV)
which does exactly that, and introduces a new exit reason to report the
event to userspace. User space can then emulate an exception to the
guest, restart the guest, suspend the guest, or take any other
appropriate action as per the policy of the running system.
Reported-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Signed-off-by: Christoffer Dall <christoffer.dall@arm.com>
Reviewed-by: Alexander Graf <graf@amazon.com>
Signed-off-by: Marc Zyngier <maz@kernel.org>
2019-10-11 19:07:05 +08:00
|
|
|
case KVM_CAP_ARM_NISV_TO_USER:
|
2019-10-11 19:07:06 +08:00
|
|
|
case KVM_CAP_ARM_INJECT_EXT_DABT:
|
2020-11-19 03:44:01 +08:00
|
|
|
case KVM_CAP_SET_GUEST_DEBUG:
|
|
|
|
case KVM_CAP_VCPU_ATTRIBUTES:
|
2020-12-09 14:09:29 +08:00
|
|
|
case KVM_CAP_PTP_KVM:
|
2022-05-04 11:24:41 +08:00
|
|
|
case KVM_CAP_ARM_SYSTEM_SUSPEND:
|
2013-01-21 07:28:06 +08:00
|
|
|
r = 1;
|
|
|
|
break;
|
2021-04-01 21:54:46 +08:00
|
|
|
case KVM_CAP_SET_GUEST_DEBUG2:
|
|
|
|
return KVM_GUESTDBG_VALID_MASK;
|
2013-01-24 02:18:04 +08:00
|
|
|
case KVM_CAP_ARM_SET_DEVICE_ADDR:
|
|
|
|
r = 1;
|
2013-04-03 17:43:13 +08:00
|
|
|
break;
|
2013-01-21 07:28:06 +08:00
|
|
|
case KVM_CAP_NR_VCPUS:
|
2021-11-17 00:34:38 +08:00
|
|
|
/*
|
|
|
|
* ARM64 treats KVM_CAP_NR_CPUS differently from all other
|
|
|
|
* architectures, as it does not always bound it to
|
|
|
|
* KVM_CAP_MAX_VCPUS. It should not matter much because
|
|
|
|
* this is just an advisory value.
|
|
|
|
*/
|
|
|
|
r = min_t(unsigned int, num_online_cpus(),
|
|
|
|
kvm_arm_default_max_vcpus());
|
2013-01-21 07:28:06 +08:00
|
|
|
break;
|
|
|
|
case KVM_CAP_MAX_VCPUS:
|
2019-05-24 00:43:08 +08:00
|
|
|
case KVM_CAP_MAX_VCPU_ID:
|
2020-04-27 22:15:07 +08:00
|
|
|
if (kvm)
|
2022-03-05 03:48:38 +08:00
|
|
|
r = kvm->max_vcpus;
|
2020-04-27 22:15:07 +08:00
|
|
|
else
|
|
|
|
r = kvm_arm_default_max_vcpus();
|
2019-05-24 00:43:08 +08:00
|
|
|
break;
|
2016-11-02 19:55:34 +08:00
|
|
|
case KVM_CAP_MSI_DEVID:
|
|
|
|
if (!kvm)
|
|
|
|
r = -EINVAL;
|
|
|
|
else
|
|
|
|
r = kvm->arch.vgic.msis_require_devid;
|
|
|
|
break;
|
2017-02-01 19:54:11 +08:00
|
|
|
case KVM_CAP_ARM_USER_IRQ:
|
|
|
|
/*
|
|
|
|
* 1: EL1_VTIMER, EL1_PTIMER, and PMU.
|
|
|
|
* (bump this number if adding more devices)
|
|
|
|
*/
|
|
|
|
r = 1;
|
|
|
|
break;
|
2021-06-21 19:17:14 +08:00
|
|
|
case KVM_CAP_ARM_MTE:
|
|
|
|
r = system_supports_mte();
|
|
|
|
break;
|
2020-08-05 01:06:04 +08:00
|
|
|
case KVM_CAP_STEAL_TIME:
|
|
|
|
r = kvm_arm_pvtime_supported();
|
|
|
|
break;
|
2020-11-19 03:44:01 +08:00
|
|
|
case KVM_CAP_ARM_EL1_32BIT:
|
|
|
|
r = cpus_have_const_cap(ARM64_HAS_32BIT_EL1);
|
|
|
|
break;
|
|
|
|
case KVM_CAP_GUEST_DEBUG_HW_BPS:
|
|
|
|
r = get_num_brps();
|
|
|
|
break;
|
|
|
|
case KVM_CAP_GUEST_DEBUG_HW_WPS:
|
|
|
|
r = get_num_wrps();
|
|
|
|
break;
|
|
|
|
case KVM_CAP_ARM_PMU_V3:
|
|
|
|
r = kvm_arm_support_pmu_v3();
|
|
|
|
break;
|
|
|
|
case KVM_CAP_ARM_INJECT_SERROR_ESR:
|
|
|
|
r = cpus_have_const_cap(ARM64_HAS_RAS_EXTN);
|
|
|
|
break;
|
|
|
|
case KVM_CAP_ARM_VM_IPA_SIZE:
|
|
|
|
r = get_kvm_ipa_limit();
|
2013-01-21 07:28:06 +08:00
|
|
|
break;
|
2020-11-19 03:44:01 +08:00
|
|
|
case KVM_CAP_ARM_SVE:
|
|
|
|
r = system_supports_sve();
|
|
|
|
break;
|
|
|
|
case KVM_CAP_ARM_PTRAUTH_ADDRESS:
|
|
|
|
case KVM_CAP_ARM_PTRAUTH_GENERIC:
|
|
|
|
r = system_has_full_ptr_auth();
|
|
|
|
break;
|
|
|
|
default:
|
|
|
|
r = 0;
|
2013-01-21 07:28:06 +08:00
|
|
|
}
|
2020-11-19 03:44:01 +08:00
|
|
|
|
2013-01-21 07:28:06 +08:00
|
|
|
return r;
|
|
|
|
}
|
|
|
|
|
|
|
|
long kvm_arch_dev_ioctl(struct file *filp,
|
|
|
|
unsigned int ioctl, unsigned long arg)
|
|
|
|
{
|
|
|
|
return -EINVAL;
|
|
|
|
}
|
|
|
|
|
2018-05-15 19:37:37 +08:00
|
|
|
struct kvm *kvm_arch_alloc_vm(void)
|
|
|
|
{
|
2021-09-07 20:31:12 +08:00
|
|
|
size_t sz = sizeof(struct kvm);
|
|
|
|
|
2018-05-15 19:37:37 +08:00
|
|
|
if (!has_vhe())
|
2021-09-07 20:31:12 +08:00
|
|
|
return kzalloc(sz, GFP_KERNEL_ACCOUNT);
|
2018-05-15 19:37:37 +08:00
|
|
|
|
2021-09-07 20:31:12 +08:00
|
|
|
return __vmalloc(sz, GFP_KERNEL_ACCOUNT | __GFP_HIGHMEM | __GFP_ZERO);
|
2018-05-15 19:37:37 +08:00
|
|
|
}
|
|
|
|
|
2019-12-19 05:55:09 +08:00
|
|
|
int kvm_arch_vcpu_precreate(struct kvm *kvm, unsigned int id)
|
|
|
|
{
|
|
|
|
if (irqchip_in_kernel(kvm) && vgic_initialized(kvm))
|
|
|
|
return -EBUSY;
|
|
|
|
|
2022-03-05 03:48:38 +08:00
|
|
|
if (id >= kvm->max_vcpus)
|
2019-12-19 05:55:09 +08:00
|
|
|
return -EINVAL;
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2019-12-19 05:55:15 +08:00
|
|
|
int kvm_arch_vcpu_create(struct kvm_vcpu *vcpu)
|
2013-01-21 07:28:06 +08:00
|
|
|
{
|
2019-12-19 05:55:25 +08:00
|
|
|
int err;
|
|
|
|
|
|
|
|
/* Force users to call KVM_ARM_VCPU_INIT */
|
|
|
|
vcpu->arch.target = -1;
|
|
|
|
bitmap_zero(vcpu->arch.features, KVM_VCPU_MAX_FEATURES);
|
|
|
|
|
2020-07-03 10:35:41 +08:00
|
|
|
vcpu->arch.mmu_page_cache.gfp_zero = __GFP_ZERO;
|
|
|
|
|
2019-12-19 05:55:25 +08:00
|
|
|
/* Set up the timer */
|
|
|
|
kvm_timer_vcpu_init(vcpu);
|
|
|
|
|
|
|
|
kvm_pmu_vcpu_init(vcpu);
|
|
|
|
|
|
|
|
kvm_arm_reset_debug_ptr(vcpu);
|
|
|
|
|
|
|
|
kvm_arm_pvtime_vcpu_init(&vcpu->arch);
|
|
|
|
|
2019-01-05 04:09:05 +08:00
|
|
|
vcpu->arch.hw_mmu = &vcpu->kvm->arch.mmu;
|
|
|
|
|
2019-12-19 05:55:25 +08:00
|
|
|
err = kvm_vgic_vcpu_init(vcpu);
|
|
|
|
if (err)
|
|
|
|
return err;
|
|
|
|
|
2021-12-16 00:12:23 +08:00
|
|
|
return kvm_share_hyp(vcpu, vcpu + 1);
|
2013-01-21 07:28:06 +08:00
|
|
|
}
|
|
|
|
|
2014-12-04 22:47:07 +08:00
|
|
|
void kvm_arch_vcpu_postcreate(struct kvm_vcpu *vcpu)
|
2013-01-21 07:28:06 +08:00
|
|
|
{
|
|
|
|
}
|
|
|
|
|
2019-12-19 05:55:04 +08:00
|
|
|
void kvm_arch_vcpu_destroy(struct kvm_vcpu *vcpu)
|
2013-01-21 07:28:06 +08:00
|
|
|
{
|
2021-10-14 19:13:06 +08:00
|
|
|
if (vcpu_has_run_once(vcpu) && unlikely(!irqchip_in_kernel(vcpu->kvm)))
|
2018-01-26 01:32:29 +08:00
|
|
|
static_branch_dec(&userspace_irqchip_in_use);
|
|
|
|
|
2020-09-11 21:25:09 +08:00
|
|
|
kvm_mmu_free_memory_cache(&vcpu->arch.mmu_page_cache);
|
2013-01-24 02:21:59 +08:00
|
|
|
kvm_timer_vcpu_terminate(vcpu);
|
2015-09-11 15:18:05 +08:00
|
|
|
kvm_pmu_vcpu_destroy(vcpu);
|
2019-12-19 05:55:27 +08:00
|
|
|
|
|
|
|
kvm_arm_vcpu_destroy(vcpu);
|
2013-01-21 07:28:06 +08:00
|
|
|
}
|
|
|
|
|
arm/arm64: KVM: arch_timer: Only schedule soft timer on vcpu_block
We currently schedule a soft timer every time we exit the guest if the
timer did not expire while running the guest. This is really not
necessary, because the only work we do in the timer work function is to
kick the vcpu.
Kicking the vcpu does two things:
(1) If the vpcu thread is on a waitqueue, make it runnable and remove it
from the waitqueue.
(2) If the vcpu is running on a different physical CPU from the one
doing the kick, it sends a reschedule IPI.
The second case cannot happen, because the soft timer is only ever
scheduled when the vcpu is not running. The first case is only relevant
when the vcpu thread is on a waitqueue, which is only the case when the
vcpu thread has called kvm_vcpu_block().
Therefore, we only need to make sure a timer is scheduled for
kvm_vcpu_block(), which we do by encapsulating all calls to
kvm_vcpu_block() with kvm_timer_{un}schedule calls.
Additionally, we only schedule a soft timer if the timer is enabled and
unmasked, since it is useless otherwise.
Note that theoretically userspace can use the SET_ONE_REG interface to
change registers that should cause the timer to fire, even if the vcpu
is blocked without a scheduled timer, but this case was not supported
before this patch and we leave it for future work for now.
Signed-off-by: Christoffer Dall <christoffer.dall@linaro.org>
2015-08-26 01:48:21 +08:00
|
|
|
void kvm_arch_vcpu_blocking(struct kvm_vcpu *vcpu)
|
|
|
|
{
|
KVM: arm64: Move vGIC v4 handling for WFI out arch callback hook
Move the put and reload of the vGIC out of the block/unblock callbacks
and into a dedicated WFI helper. Functionally, this is nearly a nop as
the block hook is called at the very beginning of kvm_vcpu_block(), and
the only code in kvm_vcpu_block() after the unblock hook is to update the
halt-polling controls, i.e. can only affect the next WFI.
Back when the arch (un)blocking hooks were added by commits 3217f7c25bca
("KVM: Add kvm_arch_vcpu_{un}blocking callbacks) and d35268da6687
("arm/arm64: KVM: arch_timer: Only schedule soft timer on vcpu_block"),
the hooks were invoked only when KVM was about to "block", i.e. schedule
out the vCPU. The use case at the time was to schedule a timer in the
host based on the earliest timer in the guest in order to wake the
blocking vCPU when the emulated guest timer fired. Commit accb99bcd0ca
("KVM: arm/arm64: Simplify bg_timer programming") reworked the timer
logic to be even more precise, by waiting until the vCPU was actually
scheduled out, and so move the timer logic from the (un)blocking hooks to
vcpu_load/put.
In the meantime, the hooks gained usage for enabling vGIC v4 doorbells in
commit df9ba95993b9 ("KVM: arm/arm64: GICv4: Use the doorbell interrupt
as an unblocking source"), and added related logic for the VMCR in commit
5eeaf10eec39 ("KVM: arm/arm64: Sync ICH_VMCR_EL2 back when about to block").
Finally, commit 07ab0f8d9a12 ("KVM: Call kvm_arch_vcpu_blocking early
into the blocking sequence") hoisted the (un)blocking hooks so that they
wrapped KVM's halt-polling logic in addition to the core "block" logic.
In other words, the original need for arch hooks to take action _only_
in the block path is long since gone.
Cc: Oliver Upton <oupton@google.com>
Cc: Marc Zyngier <maz@kernel.org>
Signed-off-by: Sean Christopherson <seanjc@google.com>
Message-Id: <20211009021236.4122790-11-seanjc@google.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2021-10-09 10:12:03 +08:00
|
|
|
|
arm/arm64: KVM: arch_timer: Only schedule soft timer on vcpu_block
We currently schedule a soft timer every time we exit the guest if the
timer did not expire while running the guest. This is really not
necessary, because the only work we do in the timer work function is to
kick the vcpu.
Kicking the vcpu does two things:
(1) If the vpcu thread is on a waitqueue, make it runnable and remove it
from the waitqueue.
(2) If the vcpu is running on a different physical CPU from the one
doing the kick, it sends a reschedule IPI.
The second case cannot happen, because the soft timer is only ever
scheduled when the vcpu is not running. The first case is only relevant
when the vcpu thread is on a waitqueue, which is only the case when the
vcpu thread has called kvm_vcpu_block().
Therefore, we only need to make sure a timer is scheduled for
kvm_vcpu_block(), which we do by encapsulating all calls to
kvm_vcpu_block() with kvm_timer_{un}schedule calls.
Additionally, we only schedule a soft timer if the timer is enabled and
unmasked, since it is useless otherwise.
Note that theoretically userspace can use the SET_ONE_REG interface to
change registers that should cause the timer to fire, even if the vcpu
is blocked without a scheduled timer, but this case was not supported
before this patch and we leave it for future work for now.
Signed-off-by: Christoffer Dall <christoffer.dall@linaro.org>
2015-08-26 01:48:21 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
void kvm_arch_vcpu_unblocking(struct kvm_vcpu *vcpu)
|
|
|
|
{
|
KVM: arm64: Move vGIC v4 handling for WFI out arch callback hook
Move the put and reload of the vGIC out of the block/unblock callbacks
and into a dedicated WFI helper. Functionally, this is nearly a nop as
the block hook is called at the very beginning of kvm_vcpu_block(), and
the only code in kvm_vcpu_block() after the unblock hook is to update the
halt-polling controls, i.e. can only affect the next WFI.
Back when the arch (un)blocking hooks were added by commits 3217f7c25bca
("KVM: Add kvm_arch_vcpu_{un}blocking callbacks) and d35268da6687
("arm/arm64: KVM: arch_timer: Only schedule soft timer on vcpu_block"),
the hooks were invoked only when KVM was about to "block", i.e. schedule
out the vCPU. The use case at the time was to schedule a timer in the
host based on the earliest timer in the guest in order to wake the
blocking vCPU when the emulated guest timer fired. Commit accb99bcd0ca
("KVM: arm/arm64: Simplify bg_timer programming") reworked the timer
logic to be even more precise, by waiting until the vCPU was actually
scheduled out, and so move the timer logic from the (un)blocking hooks to
vcpu_load/put.
In the meantime, the hooks gained usage for enabling vGIC v4 doorbells in
commit df9ba95993b9 ("KVM: arm/arm64: GICv4: Use the doorbell interrupt
as an unblocking source"), and added related logic for the VMCR in commit
5eeaf10eec39 ("KVM: arm/arm64: Sync ICH_VMCR_EL2 back when about to block").
Finally, commit 07ab0f8d9a12 ("KVM: Call kvm_arch_vcpu_blocking early
into the blocking sequence") hoisted the (un)blocking hooks so that they
wrapped KVM's halt-polling logic in addition to the core "block" logic.
In other words, the original need for arch hooks to take action _only_
in the block path is long since gone.
Cc: Oliver Upton <oupton@google.com>
Cc: Marc Zyngier <maz@kernel.org>
Signed-off-by: Sean Christopherson <seanjc@google.com>
Message-Id: <20211009021236.4122790-11-seanjc@google.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2021-10-09 10:12:03 +08:00
|
|
|
|
arm/arm64: KVM: arch_timer: Only schedule soft timer on vcpu_block
We currently schedule a soft timer every time we exit the guest if the
timer did not expire while running the guest. This is really not
necessary, because the only work we do in the timer work function is to
kick the vcpu.
Kicking the vcpu does two things:
(1) If the vpcu thread is on a waitqueue, make it runnable and remove it
from the waitqueue.
(2) If the vcpu is running on a different physical CPU from the one
doing the kick, it sends a reschedule IPI.
The second case cannot happen, because the soft timer is only ever
scheduled when the vcpu is not running. The first case is only relevant
when the vcpu thread is on a waitqueue, which is only the case when the
vcpu thread has called kvm_vcpu_block().
Therefore, we only need to make sure a timer is scheduled for
kvm_vcpu_block(), which we do by encapsulating all calls to
kvm_vcpu_block() with kvm_timer_{un}schedule calls.
Additionally, we only schedule a soft timer if the timer is enabled and
unmasked, since it is useless otherwise.
Note that theoretically userspace can use the SET_ONE_REG interface to
change registers that should cause the timer to fire, even if the vcpu
is blocked without a scheduled timer, but this case was not supported
before this patch and we leave it for future work for now.
Signed-off-by: Christoffer Dall <christoffer.dall@linaro.org>
2015-08-26 01:48:21 +08:00
|
|
|
}
|
|
|
|
|
2013-01-21 07:28:06 +08:00
|
|
|
void kvm_arch_vcpu_load(struct kvm_vcpu *vcpu, int cpu)
|
|
|
|
{
|
2019-01-05 04:09:05 +08:00
|
|
|
struct kvm_s2_mmu *mmu;
|
2016-10-19 01:37:49 +08:00
|
|
|
int *last_ran;
|
|
|
|
|
2019-01-05 04:09:05 +08:00
|
|
|
mmu = vcpu->arch.hw_mmu;
|
|
|
|
last_ran = this_cpu_ptr(mmu->last_vcpu_ran);
|
2016-10-19 01:37:49 +08:00
|
|
|
|
|
|
|
/*
|
2021-03-04 00:45:05 +08:00
|
|
|
* We guarantee that both TLBs and I-cache are private to each
|
|
|
|
* vcpu. If detecting that a vcpu from the same VM has
|
|
|
|
* previously run on the same physical CPU, call into the
|
|
|
|
* hypervisor code to nuke the relevant contexts.
|
|
|
|
*
|
2016-10-19 01:37:49 +08:00
|
|
|
* We might get preempted before the vCPU actually runs, but
|
|
|
|
* over-invalidation doesn't affect correctness.
|
|
|
|
*/
|
|
|
|
if (*last_ran != vcpu->vcpu_id) {
|
2021-03-04 00:45:05 +08:00
|
|
|
kvm_call_hyp(__kvm_flush_cpu_context, mmu);
|
2016-10-19 01:37:49 +08:00
|
|
|
*last_ran = vcpu->vcpu_id;
|
|
|
|
}
|
|
|
|
|
2013-01-21 07:28:08 +08:00
|
|
|
vcpu->cpu = cpu;
|
2013-01-21 07:28:09 +08:00
|
|
|
|
2016-03-24 18:21:04 +08:00
|
|
|
kvm_vgic_load(vcpu);
|
KVM: arm/arm64: Avoid timer save/restore in vcpu entry/exit
We don't need to save and restore the hardware timer state and examine
if it generates interrupts on on every entry/exit to the guest. The
timer hardware is perfectly capable of telling us when it has expired
by signaling interrupts.
When taking a vtimer interrupt in the host, we don't want to mess with
the timer configuration, we just want to forward the physical interrupt
to the guest as a virtual interrupt. We can use the split priority drop
and deactivate feature of the GIC to do this, which leaves an EOI'ed
interrupt active on the physical distributor, making sure we don't keep
taking timer interrupts which would prevent the guest from running. We
can then forward the physical interrupt to the VM using the HW bit in
the LR of the GIC, like we do already, which lets the guest directly
deactivate both the physical and virtual timer simultaneously, allowing
the timer hardware to exit the VM and generate a new physical interrupt
when the timer output is again asserted later on.
We do need to capture this state when migrating VCPUs between physical
CPUs, however, which we use the vcpu put/load functions for, which are
called through preempt notifiers whenever the thread is scheduled away
from the CPU or called directly if we return from the ioctl to
userspace.
One caveat is that we have to save and restore the timer state in both
kvm_timer_vcpu_[put/load] and kvm_timer_[schedule/unschedule], because
we can have the following flows:
1. kvm_vcpu_block
2. kvm_timer_schedule
3. schedule
4. kvm_timer_vcpu_put (preempt notifier)
5. schedule (vcpu thread gets scheduled back)
6. kvm_timer_vcpu_load (preempt notifier)
7. kvm_timer_unschedule
And a version where we don't actually call schedule:
1. kvm_vcpu_block
2. kvm_timer_schedule
7. kvm_timer_unschedule
Since kvm_timer_[schedule/unschedule] may not be followed by put/load,
but put/load also may be called independently, we call the timer
save/restore functions from both paths. Since they rely on the loaded
flag to never save/restore when unnecessary, this doesn't cause any
harm, and we ensure that all invokations of either set of functions work
as intended.
An added benefit beyond not having to read and write the timer sysregs
on every entry and exit is that we no longer have to actively write the
active state to the physical distributor, because we configured the
irq for the vtimer to only get a priority drop when handling the
interrupt in the GIC driver (we called irq_set_vcpu_affinity()), and
the interrupt stays active after firing on the host.
Reviewed-by: Marc Zyngier <marc.zyngier@arm.com>
Signed-off-by: Christoffer Dall <cdall@linaro.org>
2016-10-17 02:30:38 +08:00
|
|
|
kvm_timer_vcpu_load(vcpu);
|
2020-06-25 21:14:16 +08:00
|
|
|
if (has_vhe())
|
|
|
|
kvm_vcpu_load_sysregs_vhe(vcpu);
|
2018-04-06 21:55:59 +08:00
|
|
|
kvm_arch_vcpu_load_fp(vcpu);
|
2019-04-10 03:22:15 +08:00
|
|
|
kvm_vcpu_pmu_restore_guest(vcpu);
|
2019-10-21 23:28:18 +08:00
|
|
|
if (kvm_arm_is_pvtime_enabled(&vcpu->arch))
|
|
|
|
kvm_make_request(KVM_REQ_RECORD_STEAL, vcpu);
|
2018-06-21 17:43:59 +08:00
|
|
|
|
|
|
|
if (single_task_running())
|
2019-11-08 00:04:12 +08:00
|
|
|
vcpu_clear_wfx_traps(vcpu);
|
2018-06-21 17:43:59 +08:00
|
|
|
else
|
2019-11-08 00:04:12 +08:00
|
|
|
vcpu_set_wfx_traps(vcpu);
|
KVM: arm/arm64: Context-switch ptrauth registers
When pointer authentication is supported, a guest may wish to use it.
This patch adds the necessary KVM infrastructure for this to work, with
a semi-lazy context switch of the pointer auth state.
Pointer authentication feature is only enabled when VHE is built
in the kernel and present in the CPU implementation so only VHE code
paths are modified.
When we schedule a vcpu, we disable guest usage of pointer
authentication instructions and accesses to the keys. While these are
disabled, we avoid context-switching the keys. When we trap the guest
trying to use pointer authentication functionality, we change to eagerly
context-switching the keys, and enable the feature. The next time the
vcpu is scheduled out/in, we start again. However the host key save is
optimized and implemented inside ptrauth instruction/register access
trap.
Pointer authentication consists of address authentication and generic
authentication, and CPUs in a system might have varied support for
either. Where support for either feature is not uniform, it is hidden
from guests via ID register emulation, as a result of the cpufeature
framework in the host.
Unfortunately, address authentication and generic authentication cannot
be trapped separately, as the architecture provides a single EL2 trap
covering both. If we wish to expose one without the other, we cannot
prevent a (badly-written) guest from intermittently using a feature
which is not uniformly supported (when scheduled on a physical CPU which
supports the relevant feature). Hence, this patch expects both type of
authentication to be present in a cpu.
This switch of key is done from guest enter/exit assembly as preparation
for the upcoming in-kernel pointer authentication support. Hence, these
key switching routines are not implemented in C code as they may cause
pointer authentication key signing error in some situations.
Signed-off-by: Mark Rutland <mark.rutland@arm.com>
[Only VHE, key switch in full assembly, vcpu_has_ptrauth checks
, save host key in ptrauth exception trap]
Signed-off-by: Amit Daniel Kachhap <amit.kachhap@arm.com>
Reviewed-by: Julien Thierry <julien.thierry@arm.com>
Cc: Christoffer Dall <christoffer.dall@arm.com>
Cc: kvmarm@lists.cs.columbia.edu
[maz: various fixups]
Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
2019-04-23 12:42:35 +08:00
|
|
|
|
2020-06-04 18:14:00 +08:00
|
|
|
if (vcpu_has_ptrauth(vcpu))
|
2020-06-04 01:24:01 +08:00
|
|
|
vcpu_ptrauth_disable(vcpu);
|
2021-04-06 00:42:53 +08:00
|
|
|
kvm_arch_vcpu_load_debug_state_flags(vcpu);
|
2022-01-28 00:17:59 +08:00
|
|
|
|
|
|
|
if (!cpumask_test_cpu(smp_processor_id(), vcpu->kvm->arch.supported_cpus))
|
|
|
|
vcpu_set_on_unsupported_cpu(vcpu);
|
2013-01-21 07:28:06 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
void kvm_arch_vcpu_put(struct kvm_vcpu *vcpu)
|
|
|
|
{
|
2021-04-06 00:42:53 +08:00
|
|
|
kvm_arch_vcpu_put_debug_state_flags(vcpu);
|
2018-04-06 21:55:59 +08:00
|
|
|
kvm_arch_vcpu_put_fp(vcpu);
|
2020-06-25 21:14:16 +08:00
|
|
|
if (has_vhe())
|
|
|
|
kvm_vcpu_put_sysregs_vhe(vcpu);
|
KVM: arm/arm64: Avoid timer save/restore in vcpu entry/exit
We don't need to save and restore the hardware timer state and examine
if it generates interrupts on on every entry/exit to the guest. The
timer hardware is perfectly capable of telling us when it has expired
by signaling interrupts.
When taking a vtimer interrupt in the host, we don't want to mess with
the timer configuration, we just want to forward the physical interrupt
to the guest as a virtual interrupt. We can use the split priority drop
and deactivate feature of the GIC to do this, which leaves an EOI'ed
interrupt active on the physical distributor, making sure we don't keep
taking timer interrupts which would prevent the guest from running. We
can then forward the physical interrupt to the VM using the HW bit in
the LR of the GIC, like we do already, which lets the guest directly
deactivate both the physical and virtual timer simultaneously, allowing
the timer hardware to exit the VM and generate a new physical interrupt
when the timer output is again asserted later on.
We do need to capture this state when migrating VCPUs between physical
CPUs, however, which we use the vcpu put/load functions for, which are
called through preempt notifiers whenever the thread is scheduled away
from the CPU or called directly if we return from the ioctl to
userspace.
One caveat is that we have to save and restore the timer state in both
kvm_timer_vcpu_[put/load] and kvm_timer_[schedule/unschedule], because
we can have the following flows:
1. kvm_vcpu_block
2. kvm_timer_schedule
3. schedule
4. kvm_timer_vcpu_put (preempt notifier)
5. schedule (vcpu thread gets scheduled back)
6. kvm_timer_vcpu_load (preempt notifier)
7. kvm_timer_unschedule
And a version where we don't actually call schedule:
1. kvm_vcpu_block
2. kvm_timer_schedule
7. kvm_timer_unschedule
Since kvm_timer_[schedule/unschedule] may not be followed by put/load,
but put/load also may be called independently, we call the timer
save/restore functions from both paths. Since they rely on the loaded
flag to never save/restore when unnecessary, this doesn't cause any
harm, and we ensure that all invokations of either set of functions work
as intended.
An added benefit beyond not having to read and write the timer sysregs
on every entry and exit is that we no longer have to actively write the
active state to the physical distributor, because we configured the
irq for the vtimer to only get a priority drop when handling the
interrupt in the GIC driver (we called irq_set_vcpu_affinity()), and
the interrupt stays active after firing on the host.
Reviewed-by: Marc Zyngier <marc.zyngier@arm.com>
Signed-off-by: Christoffer Dall <cdall@linaro.org>
2016-10-17 02:30:38 +08:00
|
|
|
kvm_timer_vcpu_put(vcpu);
|
2016-03-24 18:21:04 +08:00
|
|
|
kvm_vgic_put(vcpu);
|
2019-04-10 03:22:15 +08:00
|
|
|
kvm_vcpu_pmu_restore_host(vcpu);
|
2021-11-22 20:18:44 +08:00
|
|
|
kvm_arm_vmid_clear_active();
|
2016-03-24 18:21:04 +08:00
|
|
|
|
2022-01-28 00:17:59 +08:00
|
|
|
vcpu_clear_on_unsupported_cpu(vcpu);
|
2013-12-12 12:29:11 +08:00
|
|
|
vcpu->cpu = -1;
|
2013-01-21 07:28:06 +08:00
|
|
|
}
|
|
|
|
|
2022-05-04 11:24:36 +08:00
|
|
|
void kvm_arm_vcpu_power_off(struct kvm_vcpu *vcpu)
|
2017-06-04 20:43:57 +08:00
|
|
|
{
|
2022-05-04 11:24:37 +08:00
|
|
|
vcpu->arch.mp_state.mp_state = KVM_MP_STATE_STOPPED;
|
2017-06-04 20:43:58 +08:00
|
|
|
kvm_make_request(KVM_REQ_SLEEP, vcpu);
|
2017-06-04 20:43:57 +08:00
|
|
|
kvm_vcpu_kick(vcpu);
|
|
|
|
}
|
|
|
|
|
2022-05-04 11:24:37 +08:00
|
|
|
bool kvm_arm_vcpu_stopped(struct kvm_vcpu *vcpu)
|
|
|
|
{
|
|
|
|
return vcpu->arch.mp_state.mp_state == KVM_MP_STATE_STOPPED;
|
|
|
|
}
|
|
|
|
|
2022-05-04 11:24:40 +08:00
|
|
|
static void kvm_arm_vcpu_suspend(struct kvm_vcpu *vcpu)
|
|
|
|
{
|
|
|
|
vcpu->arch.mp_state.mp_state = KVM_MP_STATE_SUSPENDED;
|
|
|
|
kvm_make_request(KVM_REQ_SUSPEND, vcpu);
|
|
|
|
kvm_vcpu_kick(vcpu);
|
|
|
|
}
|
|
|
|
|
|
|
|
static bool kvm_arm_vcpu_suspended(struct kvm_vcpu *vcpu)
|
|
|
|
{
|
|
|
|
return vcpu->arch.mp_state.mp_state == KVM_MP_STATE_SUSPENDED;
|
|
|
|
}
|
|
|
|
|
2013-01-21 07:28:06 +08:00
|
|
|
int kvm_arch_vcpu_ioctl_get_mpstate(struct kvm_vcpu *vcpu,
|
|
|
|
struct kvm_mp_state *mp_state)
|
|
|
|
{
|
2022-05-04 11:24:37 +08:00
|
|
|
*mp_state = vcpu->arch.mp_state;
|
2015-03-14 01:02:52 +08:00
|
|
|
|
|
|
|
return 0;
|
2013-01-21 07:28:06 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
int kvm_arch_vcpu_ioctl_set_mpstate(struct kvm_vcpu *vcpu,
|
|
|
|
struct kvm_mp_state *mp_state)
|
|
|
|
{
|
2017-12-05 04:35:31 +08:00
|
|
|
int ret = 0;
|
|
|
|
|
2015-03-14 01:02:52 +08:00
|
|
|
switch (mp_state->mp_state) {
|
|
|
|
case KVM_MP_STATE_RUNNABLE:
|
2022-05-04 11:24:37 +08:00
|
|
|
vcpu->arch.mp_state = *mp_state;
|
2015-03-14 01:02:52 +08:00
|
|
|
break;
|
|
|
|
case KVM_MP_STATE_STOPPED:
|
2022-05-04 11:24:36 +08:00
|
|
|
kvm_arm_vcpu_power_off(vcpu);
|
2015-03-14 01:02:52 +08:00
|
|
|
break;
|
2022-05-04 11:24:40 +08:00
|
|
|
case KVM_MP_STATE_SUSPENDED:
|
|
|
|
kvm_arm_vcpu_suspend(vcpu);
|
2015-03-14 01:02:52 +08:00
|
|
|
break;
|
|
|
|
default:
|
2017-12-05 04:35:31 +08:00
|
|
|
ret = -EINVAL;
|
2015-03-14 01:02:52 +08:00
|
|
|
}
|
|
|
|
|
2017-12-05 04:35:31 +08:00
|
|
|
return ret;
|
2013-01-21 07:28:06 +08:00
|
|
|
}
|
|
|
|
|
2013-01-21 07:28:09 +08:00
|
|
|
/**
|
|
|
|
* kvm_arch_vcpu_runnable - determine if the vcpu can be scheduled
|
|
|
|
* @v: The VCPU pointer
|
|
|
|
*
|
|
|
|
* If the guest CPU is not waiting for interrupts or an interrupt line is
|
|
|
|
* asserted, the CPU is by definition runnable.
|
|
|
|
*/
|
2013-01-21 07:28:06 +08:00
|
|
|
int kvm_arch_vcpu_runnable(struct kvm_vcpu *v)
|
|
|
|
{
|
2017-08-03 18:09:05 +08:00
|
|
|
bool irq_lines = *vcpu_hcr(v) & (HCR_VI | HCR_VF);
|
|
|
|
return ((irq_lines || kvm_vgic_vcpu_pending_irq(v))
|
2022-05-04 11:24:37 +08:00
|
|
|
&& !kvm_arm_vcpu_stopped(v) && !v->arch.pause);
|
2013-01-21 07:28:06 +08:00
|
|
|
}
|
|
|
|
|
2017-08-08 12:05:32 +08:00
|
|
|
bool kvm_arch_vcpu_in_kernel(struct kvm_vcpu *vcpu)
|
|
|
|
{
|
2017-08-08 12:05:35 +08:00
|
|
|
return vcpu_mode_priv(vcpu);
|
2017-08-08 12:05:32 +08:00
|
|
|
}
|
|
|
|
|
2022-01-13 08:26:58 +08:00
|
|
|
#ifdef CONFIG_GUEST_PERF_EVENTS
|
2021-11-11 10:07:33 +08:00
|
|
|
unsigned long kvm_arch_vcpu_get_ip(struct kvm_vcpu *vcpu)
|
|
|
|
{
|
|
|
|
return *vcpu_pc(vcpu);
|
|
|
|
}
|
2022-01-13 08:26:58 +08:00
|
|
|
#endif
|
2021-11-11 10:07:33 +08:00
|
|
|
|
2021-10-14 18:42:38 +08:00
|
|
|
static int kvm_vcpu_initialized(struct kvm_vcpu *vcpu)
|
2021-10-14 18:30:42 +08:00
|
|
|
{
|
2021-10-14 18:42:38 +08:00
|
|
|
return vcpu->arch.target >= 0;
|
2021-10-14 18:30:42 +08:00
|
|
|
}
|
|
|
|
|
2021-10-14 18:42:38 +08:00
|
|
|
/*
|
|
|
|
* Handle both the initialisation that is being done when the vcpu is
|
|
|
|
* run for the first time, as well as the updates that must be
|
|
|
|
* performed each time we get a new thread dealing with this vcpu.
|
|
|
|
*/
|
|
|
|
int kvm_arch_vcpu_run_pid_change(struct kvm_vcpu *vcpu)
|
KVM: ARM: World-switch implementation
Provides complete world-switch implementation to switch to other guests
running in non-secure modes. Includes Hyp exception handlers that
capture necessary exception information and stores the information on
the VCPU and KVM structures.
The following Hyp-ABI is also documented in the code:
Hyp-ABI: Calling HYP-mode functions from host (in SVC mode):
Switching to Hyp mode is done through a simple HVC #0 instruction. The
exception vector code will check that the HVC comes from VMID==0 and if
so will push the necessary state (SPSR, lr_usr) on the Hyp stack.
- r0 contains a pointer to a HYP function
- r1, r2, and r3 contain arguments to the above function.
- The HYP function will be called with its arguments in r0, r1 and r2.
On HYP function return, we return directly to SVC.
A call to a function executing in Hyp mode is performed like the following:
<svc code>
ldr r0, =BSYM(my_hyp_fn)
ldr r1, =my_param
hvc #0 ; Call my_hyp_fn(my_param) from HYP mode
<svc code>
Otherwise, the world-switch is pretty straight-forward. All state that
can be modified by the guest is first backed up on the Hyp stack and the
VCPU values is loaded onto the hardware. State, which is not loaded, but
theoretically modifiable by the guest is protected through the
virtualiation features to generate a trap and cause software emulation.
Upon guest returns, all state is restored from hardware onto the VCPU
struct and the original state is restored from the Hyp-stack onto the
hardware.
SMP support using the VMPIDR calculated on the basis of the host MPIDR
and overriding the low bits with KVM vcpu_id contributed by Marc Zyngier.
Reuse of VMIDs has been implemented by Antonios Motakis and adapated from
a separate patch into the appropriate patches introducing the
functionality. Note that the VMIDs are stored per VM as required by the ARM
architecture reference manual.
To support VFP/NEON we trap those instructions using the HPCTR. When
we trap, we switch the FPU. After a guest exit, the VFP state is
returned to the host. When disabling access to floating point
instructions, we also mask FPEXC_EN in order to avoid the guest
receiving Undefined instruction exceptions before we have a chance to
switch back the floating point state. We are reusing vfp_hard_struct,
so we depend on VFPv3 being enabled in the host kernel, if not, we still
trap cp10 and cp11 in order to inject an undefined instruction exception
whenever the guest tries to use VFP/NEON. VFP/NEON developed by
Antionios Motakis and Rusty Russell.
Aborts that are permission faults, and not stage-1 page table walk, do
not report the faulting address in the HPFAR. We have to resolve the
IPA, and store it just like the HPFAR register on the VCPU struct. If
the IPA cannot be resolved, it means another CPU is playing with the
page tables, and we simply restart the guest. This quirk was fixed by
Marc Zyngier.
Reviewed-by: Will Deacon <will.deacon@arm.com>
Reviewed-by: Marcelo Tosatti <mtosatti@redhat.com>
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Signed-off-by: Antonios Motakis <a.motakis@virtualopensystems.com>
Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
Signed-off-by: Christoffer Dall <c.dall@virtualopensystems.com>
2013-01-21 07:47:42 +08:00
|
|
|
{
|
2014-12-13 04:19:23 +08:00
|
|
|
struct kvm *kvm = vcpu->kvm;
|
2021-10-14 18:42:38 +08:00
|
|
|
int ret;
|
2013-09-24 05:55:55 +08:00
|
|
|
|
2021-10-14 18:42:38 +08:00
|
|
|
if (!kvm_vcpu_initialized(vcpu))
|
|
|
|
return -ENOEXEC;
|
KVM: ARM: World-switch implementation
Provides complete world-switch implementation to switch to other guests
running in non-secure modes. Includes Hyp exception handlers that
capture necessary exception information and stores the information on
the VCPU and KVM structures.
The following Hyp-ABI is also documented in the code:
Hyp-ABI: Calling HYP-mode functions from host (in SVC mode):
Switching to Hyp mode is done through a simple HVC #0 instruction. The
exception vector code will check that the HVC comes from VMID==0 and if
so will push the necessary state (SPSR, lr_usr) on the Hyp stack.
- r0 contains a pointer to a HYP function
- r1, r2, and r3 contain arguments to the above function.
- The HYP function will be called with its arguments in r0, r1 and r2.
On HYP function return, we return directly to SVC.
A call to a function executing in Hyp mode is performed like the following:
<svc code>
ldr r0, =BSYM(my_hyp_fn)
ldr r1, =my_param
hvc #0 ; Call my_hyp_fn(my_param) from HYP mode
<svc code>
Otherwise, the world-switch is pretty straight-forward. All state that
can be modified by the guest is first backed up on the Hyp stack and the
VCPU values is loaded onto the hardware. State, which is not loaded, but
theoretically modifiable by the guest is protected through the
virtualiation features to generate a trap and cause software emulation.
Upon guest returns, all state is restored from hardware onto the VCPU
struct and the original state is restored from the Hyp-stack onto the
hardware.
SMP support using the VMPIDR calculated on the basis of the host MPIDR
and overriding the low bits with KVM vcpu_id contributed by Marc Zyngier.
Reuse of VMIDs has been implemented by Antonios Motakis and adapated from
a separate patch into the appropriate patches introducing the
functionality. Note that the VMIDs are stored per VM as required by the ARM
architecture reference manual.
To support VFP/NEON we trap those instructions using the HPCTR. When
we trap, we switch the FPU. After a guest exit, the VFP state is
returned to the host. When disabling access to floating point
instructions, we also mask FPEXC_EN in order to avoid the guest
receiving Undefined instruction exceptions before we have a chance to
switch back the floating point state. We are reusing vfp_hard_struct,
so we depend on VFPv3 being enabled in the host kernel, if not, we still
trap cp10 and cp11 in order to inject an undefined instruction exception
whenever the guest tries to use VFP/NEON. VFP/NEON developed by
Antionios Motakis and Rusty Russell.
Aborts that are permission faults, and not stage-1 page table walk, do
not report the faulting address in the HPFAR. We have to resolve the
IPA, and store it just like the HPFAR register on the VCPU struct. If
the IPA cannot be resolved, it means another CPU is playing with the
page tables, and we simply restart the guest. This quirk was fixed by
Marc Zyngier.
Reviewed-by: Will Deacon <will.deacon@arm.com>
Reviewed-by: Marcelo Tosatti <mtosatti@redhat.com>
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Signed-off-by: Antonios Motakis <a.motakis@virtualopensystems.com>
Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
Signed-off-by: Christoffer Dall <c.dall@virtualopensystems.com>
2013-01-21 07:47:42 +08:00
|
|
|
|
2018-12-19 22:27:01 +08:00
|
|
|
if (!kvm_arm_vcpu_is_finalized(vcpu))
|
|
|
|
return -EPERM;
|
|
|
|
|
2021-10-14 18:42:38 +08:00
|
|
|
ret = kvm_arch_vcpu_run_map_fp(vcpu);
|
|
|
|
if (ret)
|
|
|
|
return ret;
|
|
|
|
|
2021-10-14 19:13:06 +08:00
|
|
|
if (likely(vcpu_has_run_once(vcpu)))
|
2021-10-14 18:42:38 +08:00
|
|
|
return 0;
|
2013-01-21 07:28:13 +08:00
|
|
|
|
2021-04-07 22:48:57 +08:00
|
|
|
kvm_arm_vcpu_init_debug(vcpu);
|
|
|
|
|
2017-10-28 01:57:51 +08:00
|
|
|
if (likely(irqchip_in_kernel(kvm))) {
|
|
|
|
/*
|
|
|
|
* Map the VGIC hardware resources before running a vcpu the
|
|
|
|
* first time on this VM.
|
|
|
|
*/
|
2020-12-01 23:01:55 +08:00
|
|
|
ret = kvm_vgic_map_resources(kvm);
|
|
|
|
if (ret)
|
|
|
|
return ret;
|
2013-01-22 08:36:16 +08:00
|
|
|
}
|
|
|
|
|
KVM: arm/arm64: Support arch timers with a userspace gic
If you're running with a userspace gic or other interrupt controller
(that is no vgic in the kernel), then you have so far not been able to
use the architected timers, because the output of the architected
timers, which are driven inside the kernel, was a kernel-only construct
between the arch timer code and the vgic.
This patch implements the new KVM_CAP_ARM_USER_IRQ feature, where we use a
side channel on the kvm_run structure, run->s.regs.device_irq_level, to
always notify userspace of the timer output levels when using a userspace
irqchip.
This works by ensuring that before we enter the guest, if the timer
output level has changed compared to what we last told userspace, we
don't enter the guest, but instead return to userspace to notify it of
the new level. If we are exiting, because of an MMIO for example, and
the level changed at the same time, the value is also updated and
userspace can sample the line as it needs. This is nicely achieved
simply always updating the timer_irq_level field after the main run
loop.
Note that the kvm_timer_update_irq trace event is changed to show the
host IRQ number for the timer instead of the guest IRQ number, because
the kernel no longer know which IRQ userspace wires up the timer signal
to.
Also note that this patch implements all required functionality but does
not yet advertise the capability.
Reviewed-by: Alexander Graf <agraf@suse.de>
Reviewed-by: Marc Zyngier <marc.zyngier@arm.com>
Signed-off-by: Alexander Graf <agraf@suse.de>
Signed-off-by: Christoffer Dall <christoffer.dall@linaro.org>
2016-09-28 03:08:06 +08:00
|
|
|
ret = kvm_timer_enable(vcpu);
|
2017-05-02 19:41:02 +08:00
|
|
|
if (ret)
|
|
|
|
return ret;
|
|
|
|
|
|
|
|
ret = kvm_arm_pmu_v3_enable(vcpu);
|
2021-10-14 19:18:48 +08:00
|
|
|
if (ret)
|
|
|
|
return ret;
|
|
|
|
|
|
|
|
if (!irqchip_in_kernel(kvm)) {
|
|
|
|
/*
|
|
|
|
* Tell the rest of the code that there are userspace irqchip
|
|
|
|
* VMs in the wild.
|
|
|
|
*/
|
|
|
|
static_branch_inc(&userspace_irqchip_in_use);
|
|
|
|
}
|
2014-12-13 04:19:23 +08:00
|
|
|
|
2021-10-10 22:56:33 +08:00
|
|
|
/*
|
|
|
|
* Initialize traps for protected VMs.
|
|
|
|
* NOTE: Move to run in EL2 directly, rather than via a hypercall, once
|
|
|
|
* the code is in place for first run initialization at EL2.
|
|
|
|
*/
|
|
|
|
if (kvm_vm_is_protected(kvm))
|
|
|
|
kvm_call_hyp_nvhe(__pkvm_vcpu_init_traps, vcpu);
|
|
|
|
|
2022-01-28 00:17:54 +08:00
|
|
|
mutex_lock(&kvm->lock);
|
2022-03-12 01:39:47 +08:00
|
|
|
set_bit(KVM_ARCH_FLAG_HAS_RAN_ONCE, &kvm->arch.flags);
|
2022-01-28 00:17:54 +08:00
|
|
|
mutex_unlock(&kvm->lock);
|
|
|
|
|
2016-05-18 23:26:00 +08:00
|
|
|
return ret;
|
KVM: ARM: World-switch implementation
Provides complete world-switch implementation to switch to other guests
running in non-secure modes. Includes Hyp exception handlers that
capture necessary exception information and stores the information on
the VCPU and KVM structures.
The following Hyp-ABI is also documented in the code:
Hyp-ABI: Calling HYP-mode functions from host (in SVC mode):
Switching to Hyp mode is done through a simple HVC #0 instruction. The
exception vector code will check that the HVC comes from VMID==0 and if
so will push the necessary state (SPSR, lr_usr) on the Hyp stack.
- r0 contains a pointer to a HYP function
- r1, r2, and r3 contain arguments to the above function.
- The HYP function will be called with its arguments in r0, r1 and r2.
On HYP function return, we return directly to SVC.
A call to a function executing in Hyp mode is performed like the following:
<svc code>
ldr r0, =BSYM(my_hyp_fn)
ldr r1, =my_param
hvc #0 ; Call my_hyp_fn(my_param) from HYP mode
<svc code>
Otherwise, the world-switch is pretty straight-forward. All state that
can be modified by the guest is first backed up on the Hyp stack and the
VCPU values is loaded onto the hardware. State, which is not loaded, but
theoretically modifiable by the guest is protected through the
virtualiation features to generate a trap and cause software emulation.
Upon guest returns, all state is restored from hardware onto the VCPU
struct and the original state is restored from the Hyp-stack onto the
hardware.
SMP support using the VMPIDR calculated on the basis of the host MPIDR
and overriding the low bits with KVM vcpu_id contributed by Marc Zyngier.
Reuse of VMIDs has been implemented by Antonios Motakis and adapated from
a separate patch into the appropriate patches introducing the
functionality. Note that the VMIDs are stored per VM as required by the ARM
architecture reference manual.
To support VFP/NEON we trap those instructions using the HPCTR. When
we trap, we switch the FPU. After a guest exit, the VFP state is
returned to the host. When disabling access to floating point
instructions, we also mask FPEXC_EN in order to avoid the guest
receiving Undefined instruction exceptions before we have a chance to
switch back the floating point state. We are reusing vfp_hard_struct,
so we depend on VFPv3 being enabled in the host kernel, if not, we still
trap cp10 and cp11 in order to inject an undefined instruction exception
whenever the guest tries to use VFP/NEON. VFP/NEON developed by
Antionios Motakis and Rusty Russell.
Aborts that are permission faults, and not stage-1 page table walk, do
not report the faulting address in the HPFAR. We have to resolve the
IPA, and store it just like the HPFAR register on the VCPU struct. If
the IPA cannot be resolved, it means another CPU is playing with the
page tables, and we simply restart the guest. This quirk was fixed by
Marc Zyngier.
Reviewed-by: Will Deacon <will.deacon@arm.com>
Reviewed-by: Marcelo Tosatti <mtosatti@redhat.com>
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Signed-off-by: Antonios Motakis <a.motakis@virtualopensystems.com>
Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
Signed-off-by: Christoffer Dall <c.dall@virtualopensystems.com>
2013-01-21 07:47:42 +08:00
|
|
|
}
|
|
|
|
|
2015-03-04 18:14:34 +08:00
|
|
|
bool kvm_arch_intc_initialized(struct kvm *kvm)
|
|
|
|
{
|
|
|
|
return vgic_initialized(kvm);
|
|
|
|
}
|
|
|
|
|
2016-04-27 17:28:00 +08:00
|
|
|
void kvm_arm_halt_guest(struct kvm *kvm)
|
2015-09-26 05:41:17 +08:00
|
|
|
{
|
2021-11-17 00:04:02 +08:00
|
|
|
unsigned long i;
|
2015-09-26 05:41:17 +08:00
|
|
|
struct kvm_vcpu *vcpu;
|
|
|
|
|
|
|
|
kvm_for_each_vcpu(i, vcpu, kvm)
|
|
|
|
vcpu->arch.pause = true;
|
2017-06-04 20:43:58 +08:00
|
|
|
kvm_make_all_cpus_request(kvm, KVM_REQ_SLEEP);
|
2015-09-26 05:41:17 +08:00
|
|
|
}
|
|
|
|
|
2016-04-27 17:28:00 +08:00
|
|
|
void kvm_arm_resume_guest(struct kvm *kvm)
|
2015-09-26 05:41:17 +08:00
|
|
|
{
|
2021-11-17 00:04:02 +08:00
|
|
|
unsigned long i;
|
2015-09-26 05:41:17 +08:00
|
|
|
struct kvm_vcpu *vcpu;
|
|
|
|
|
2017-05-07 02:01:24 +08:00
|
|
|
kvm_for_each_vcpu(i, vcpu, kvm) {
|
|
|
|
vcpu->arch.pause = false;
|
2021-10-09 10:12:12 +08:00
|
|
|
__kvm_vcpu_wake_up(vcpu);
|
2017-05-07 02:01:24 +08:00
|
|
|
}
|
2015-09-26 05:41:17 +08:00
|
|
|
}
|
|
|
|
|
2022-05-04 11:24:38 +08:00
|
|
|
static void kvm_vcpu_sleep(struct kvm_vcpu *vcpu)
|
2013-01-21 07:28:13 +08:00
|
|
|
{
|
2020-04-24 13:48:37 +08:00
|
|
|
struct rcuwait *wait = kvm_arch_vcpu_get_wait(vcpu);
|
2013-01-21 07:28:13 +08:00
|
|
|
|
2020-04-24 13:48:37 +08:00
|
|
|
rcuwait_wait_event(wait,
|
2022-05-04 11:24:37 +08:00
|
|
|
(!kvm_arm_vcpu_stopped(vcpu)) && (!vcpu->arch.pause),
|
2020-04-24 13:48:37 +08:00
|
|
|
TASK_INTERRUPTIBLE);
|
2017-06-04 20:43:55 +08:00
|
|
|
|
2022-05-04 11:24:37 +08:00
|
|
|
if (kvm_arm_vcpu_stopped(vcpu) || vcpu->arch.pause) {
|
2017-06-04 20:43:55 +08:00
|
|
|
/* Awaken to handle a signal, request we sleep again later. */
|
2017-06-04 20:43:58 +08:00
|
|
|
kvm_make_request(KVM_REQ_SLEEP, vcpu);
|
2017-06-04 20:43:55 +08:00
|
|
|
}
|
2018-12-20 19:36:07 +08:00
|
|
|
|
|
|
|
/*
|
|
|
|
* Make sure we will observe a potential reset request if we've
|
|
|
|
* observed a change to the power state. Pairs with the smp_wmb() in
|
|
|
|
* kvm_psci_vcpu_on().
|
|
|
|
*/
|
|
|
|
smp_rmb();
|
2013-01-21 07:28:13 +08:00
|
|
|
}
|
|
|
|
|
KVM: arm64: Move vGIC v4 handling for WFI out arch callback hook
Move the put and reload of the vGIC out of the block/unblock callbacks
and into a dedicated WFI helper. Functionally, this is nearly a nop as
the block hook is called at the very beginning of kvm_vcpu_block(), and
the only code in kvm_vcpu_block() after the unblock hook is to update the
halt-polling controls, i.e. can only affect the next WFI.
Back when the arch (un)blocking hooks were added by commits 3217f7c25bca
("KVM: Add kvm_arch_vcpu_{un}blocking callbacks) and d35268da6687
("arm/arm64: KVM: arch_timer: Only schedule soft timer on vcpu_block"),
the hooks were invoked only when KVM was about to "block", i.e. schedule
out the vCPU. The use case at the time was to schedule a timer in the
host based on the earliest timer in the guest in order to wake the
blocking vCPU when the emulated guest timer fired. Commit accb99bcd0ca
("KVM: arm/arm64: Simplify bg_timer programming") reworked the timer
logic to be even more precise, by waiting until the vCPU was actually
scheduled out, and so move the timer logic from the (un)blocking hooks to
vcpu_load/put.
In the meantime, the hooks gained usage for enabling vGIC v4 doorbells in
commit df9ba95993b9 ("KVM: arm/arm64: GICv4: Use the doorbell interrupt
as an unblocking source"), and added related logic for the VMCR in commit
5eeaf10eec39 ("KVM: arm/arm64: Sync ICH_VMCR_EL2 back when about to block").
Finally, commit 07ab0f8d9a12 ("KVM: Call kvm_arch_vcpu_blocking early
into the blocking sequence") hoisted the (un)blocking hooks so that they
wrapped KVM's halt-polling logic in addition to the core "block" logic.
In other words, the original need for arch hooks to take action _only_
in the block path is long since gone.
Cc: Oliver Upton <oupton@google.com>
Cc: Marc Zyngier <maz@kernel.org>
Signed-off-by: Sean Christopherson <seanjc@google.com>
Message-Id: <20211009021236.4122790-11-seanjc@google.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2021-10-09 10:12:03 +08:00
|
|
|
/**
|
|
|
|
* kvm_vcpu_wfi - emulate Wait-For-Interrupt behavior
|
|
|
|
* @vcpu: The VCPU pointer
|
|
|
|
*
|
|
|
|
* Suspend execution of a vCPU until a valid wake event is detected, i.e. until
|
|
|
|
* the vCPU is runnable. The vCPU may or may not be scheduled out, depending
|
|
|
|
* on when a wake event arrives, e.g. there may already be a pending wake event.
|
|
|
|
*/
|
|
|
|
void kvm_vcpu_wfi(struct kvm_vcpu *vcpu)
|
|
|
|
{
|
|
|
|
/*
|
|
|
|
* Sync back the state of the GIC CPU interface so that we have
|
|
|
|
* the latest PMR and group enables. This ensures that
|
|
|
|
* kvm_arch_vcpu_runnable has up-to-date data to decide whether
|
|
|
|
* we have pending interrupts, e.g. when determining if the
|
|
|
|
* vCPU should block.
|
|
|
|
*
|
|
|
|
* For the same reason, we want to tell GICv4 that we need
|
|
|
|
* doorbells to be signalled, should an interrupt become pending.
|
|
|
|
*/
|
|
|
|
preempt_disable();
|
|
|
|
kvm_vgic_vmcr_sync(vcpu);
|
|
|
|
vgic_v4_put(vcpu, true);
|
|
|
|
preempt_enable();
|
|
|
|
|
2021-10-09 10:12:06 +08:00
|
|
|
kvm_vcpu_halt(vcpu);
|
2022-05-28 19:38:22 +08:00
|
|
|
vcpu_clear_flag(vcpu, IN_WFIT);
|
KVM: arm64: Move vGIC v4 handling for WFI out arch callback hook
Move the put and reload of the vGIC out of the block/unblock callbacks
and into a dedicated WFI helper. Functionally, this is nearly a nop as
the block hook is called at the very beginning of kvm_vcpu_block(), and
the only code in kvm_vcpu_block() after the unblock hook is to update the
halt-polling controls, i.e. can only affect the next WFI.
Back when the arch (un)blocking hooks were added by commits 3217f7c25bca
("KVM: Add kvm_arch_vcpu_{un}blocking callbacks) and d35268da6687
("arm/arm64: KVM: arch_timer: Only schedule soft timer on vcpu_block"),
the hooks were invoked only when KVM was about to "block", i.e. schedule
out the vCPU. The use case at the time was to schedule a timer in the
host based on the earliest timer in the guest in order to wake the
blocking vCPU when the emulated guest timer fired. Commit accb99bcd0ca
("KVM: arm/arm64: Simplify bg_timer programming") reworked the timer
logic to be even more precise, by waiting until the vCPU was actually
scheduled out, and so move the timer logic from the (un)blocking hooks to
vcpu_load/put.
In the meantime, the hooks gained usage for enabling vGIC v4 doorbells in
commit df9ba95993b9 ("KVM: arm/arm64: GICv4: Use the doorbell interrupt
as an unblocking source"), and added related logic for the VMCR in commit
5eeaf10eec39 ("KVM: arm/arm64: Sync ICH_VMCR_EL2 back when about to block").
Finally, commit 07ab0f8d9a12 ("KVM: Call kvm_arch_vcpu_blocking early
into the blocking sequence") hoisted the (un)blocking hooks so that they
wrapped KVM's halt-polling logic in addition to the core "block" logic.
In other words, the original need for arch hooks to take action _only_
in the block path is long since gone.
Cc: Oliver Upton <oupton@google.com>
Cc: Marc Zyngier <maz@kernel.org>
Signed-off-by: Sean Christopherson <seanjc@google.com>
Message-Id: <20211009021236.4122790-11-seanjc@google.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2021-10-09 10:12:03 +08:00
|
|
|
kvm_clear_request(KVM_REQ_UNHALT, vcpu);
|
|
|
|
|
|
|
|
preempt_disable();
|
|
|
|
vgic_v4_load(vcpu);
|
|
|
|
preempt_enable();
|
|
|
|
}
|
|
|
|
|
2022-05-04 11:24:40 +08:00
|
|
|
static int kvm_vcpu_suspend(struct kvm_vcpu *vcpu)
|
|
|
|
{
|
|
|
|
if (!kvm_arm_vcpu_suspended(vcpu))
|
|
|
|
return 1;
|
|
|
|
|
|
|
|
kvm_vcpu_wfi(vcpu);
|
|
|
|
|
|
|
|
/*
|
|
|
|
* The suspend state is sticky; we do not leave it until userspace
|
|
|
|
* explicitly marks the vCPU as runnable. Request that we suspend again
|
|
|
|
* later.
|
|
|
|
*/
|
|
|
|
kvm_make_request(KVM_REQ_SUSPEND, vcpu);
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Check to make sure the vCPU is actually runnable. If so, exit to
|
|
|
|
* userspace informing it of the wakeup condition.
|
|
|
|
*/
|
|
|
|
if (kvm_arch_vcpu_runnable(vcpu)) {
|
|
|
|
memset(&vcpu->run->system_event, 0, sizeof(vcpu->run->system_event));
|
|
|
|
vcpu->run->system_event.type = KVM_SYSTEM_EVENT_WAKEUP;
|
|
|
|
vcpu->run->exit_reason = KVM_EXIT_SYSTEM_EVENT;
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Otherwise, we were unblocked to process a different event, such as a
|
|
|
|
* pending signal. Return 1 and allow kvm_arch_vcpu_ioctl_run() to
|
|
|
|
* process the event.
|
|
|
|
*/
|
|
|
|
return 1;
|
|
|
|
}
|
|
|
|
|
2022-05-04 11:24:39 +08:00
|
|
|
/**
|
|
|
|
* check_vcpu_requests - check and handle pending vCPU requests
|
|
|
|
* @vcpu: the VCPU pointer
|
|
|
|
*
|
|
|
|
* Return: 1 if we should enter the guest
|
|
|
|
* 0 if we should exit to userspace
|
|
|
|
* < 0 if we should exit to userspace, where the return value indicates
|
|
|
|
* an error
|
|
|
|
*/
|
|
|
|
static int check_vcpu_requests(struct kvm_vcpu *vcpu)
|
2017-06-04 20:43:55 +08:00
|
|
|
{
|
|
|
|
if (kvm_request_pending(vcpu)) {
|
2017-06-04 20:43:58 +08:00
|
|
|
if (kvm_check_request(KVM_REQ_SLEEP, vcpu))
|
2022-05-04 11:24:38 +08:00
|
|
|
kvm_vcpu_sleep(vcpu);
|
2017-06-04 20:43:59 +08:00
|
|
|
|
2018-12-20 19:36:07 +08:00
|
|
|
if (kvm_check_request(KVM_REQ_VCPU_RESET, vcpu))
|
|
|
|
kvm_reset_vcpu(vcpu);
|
|
|
|
|
2017-06-04 20:43:59 +08:00
|
|
|
/*
|
|
|
|
* Clear IRQ_PENDING requests that were made to guarantee
|
|
|
|
* that a VCPU sees new virtual interrupts.
|
|
|
|
*/
|
|
|
|
kvm_check_request(KVM_REQ_IRQ_PENDING, vcpu);
|
2019-10-21 23:28:18 +08:00
|
|
|
|
|
|
|
if (kvm_check_request(KVM_REQ_RECORD_STEAL, vcpu))
|
|
|
|
kvm_update_stolen_time(vcpu);
|
2020-03-05 04:33:28 +08:00
|
|
|
|
|
|
|
if (kvm_check_request(KVM_REQ_RELOAD_GICv4, vcpu)) {
|
|
|
|
/* The distributor enable bits were changed */
|
|
|
|
preempt_disable();
|
|
|
|
vgic_v4_put(vcpu, false);
|
|
|
|
vgic_v4_load(vcpu);
|
|
|
|
preempt_enable();
|
|
|
|
}
|
2021-06-03 23:50:02 +08:00
|
|
|
|
|
|
|
if (kvm_check_request(KVM_REQ_RELOAD_PMU, vcpu))
|
|
|
|
kvm_pmu_handle_pmcr(vcpu,
|
|
|
|
__vcpu_sys_reg(vcpu, PMCR_EL0));
|
2022-05-04 11:24:40 +08:00
|
|
|
|
|
|
|
if (kvm_check_request(KVM_REQ_SUSPEND, vcpu))
|
|
|
|
return kvm_vcpu_suspend(vcpu);
|
2017-06-04 20:43:55 +08:00
|
|
|
}
|
2022-05-04 11:24:39 +08:00
|
|
|
|
|
|
|
return 1;
|
2017-06-04 20:43:55 +08:00
|
|
|
}
|
|
|
|
|
2021-06-09 02:02:56 +08:00
|
|
|
static bool vcpu_mode_is_bad_32bit(struct kvm_vcpu *vcpu)
|
|
|
|
{
|
|
|
|
if (likely(!vcpu_mode_is_32bit(vcpu)))
|
|
|
|
return false;
|
|
|
|
|
|
|
|
return !system_supports_32bit_el0() ||
|
|
|
|
static_branch_unlikely(&arm64_mismatched_32bit_el0);
|
|
|
|
}
|
|
|
|
|
2021-08-03 03:28:09 +08:00
|
|
|
/**
|
|
|
|
* kvm_vcpu_exit_request - returns true if the VCPU should *not* enter the guest
|
|
|
|
* @vcpu: The VCPU pointer
|
|
|
|
* @ret: Pointer to write optional return code
|
|
|
|
*
|
|
|
|
* Returns: true if the VCPU needs to return to a preemptible + interruptible
|
|
|
|
* and skip guest entry.
|
|
|
|
*
|
|
|
|
* This function disambiguates between two different types of exits: exits to a
|
|
|
|
* preemptible + interruptible kernel context and exits to userspace. For an
|
|
|
|
* exit to userspace, this function will write the return code to ret and return
|
|
|
|
* true. For an exit to preemptible + interruptible kernel context (i.e. check
|
|
|
|
* for pending work and re-enter), return true without writing to ret.
|
|
|
|
*/
|
|
|
|
static bool kvm_vcpu_exit_request(struct kvm_vcpu *vcpu, int *ret)
|
|
|
|
{
|
|
|
|
struct kvm_run *run = vcpu->run;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* If we're using a userspace irqchip, then check if we need
|
|
|
|
* to tell a userspace irqchip about timer or PMU level
|
|
|
|
* changes and if so, exit to userspace (the actual level
|
|
|
|
* state gets updated in kvm_timer_update_run and
|
|
|
|
* kvm_pmu_update_run below).
|
|
|
|
*/
|
|
|
|
if (static_branch_unlikely(&userspace_irqchip_in_use)) {
|
|
|
|
if (kvm_timer_should_notify_user(vcpu) ||
|
|
|
|
kvm_pmu_should_notify_user(vcpu)) {
|
|
|
|
*ret = -EINTR;
|
|
|
|
run->exit_reason = KVM_EXIT_INTR;
|
|
|
|
return true;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2022-01-28 00:17:59 +08:00
|
|
|
if (unlikely(vcpu_on_unsupported_cpu(vcpu))) {
|
|
|
|
run->exit_reason = KVM_EXIT_FAIL_ENTRY;
|
|
|
|
run->fail_entry.hardware_entry_failure_reason = KVM_EXIT_FAIL_ENTRY_CPU_UNSUPPORTED;
|
|
|
|
run->fail_entry.cpu = smp_processor_id();
|
|
|
|
*ret = 0;
|
|
|
|
return true;
|
|
|
|
}
|
|
|
|
|
2021-08-03 03:28:09 +08:00
|
|
|
return kvm_request_pending(vcpu) ||
|
|
|
|
xfer_to_guest_mode_work_pending();
|
|
|
|
}
|
|
|
|
|
2022-02-01 21:29:23 +08:00
|
|
|
/*
|
|
|
|
* Actually run the vCPU, entering an RCU extended quiescent state (EQS) while
|
|
|
|
* the vCPU is running.
|
|
|
|
*
|
|
|
|
* This must be noinstr as instrumentation may make use of RCU, and this is not
|
|
|
|
* safe during the EQS.
|
|
|
|
*/
|
|
|
|
static int noinstr kvm_arm_vcpu_enter_exit(struct kvm_vcpu *vcpu)
|
|
|
|
{
|
|
|
|
int ret;
|
|
|
|
|
|
|
|
guest_state_enter_irqoff();
|
|
|
|
ret = kvm_call_hyp_ret(__kvm_vcpu_run, vcpu);
|
|
|
|
guest_state_exit_irqoff();
|
|
|
|
|
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
|
KVM: ARM: World-switch implementation
Provides complete world-switch implementation to switch to other guests
running in non-secure modes. Includes Hyp exception handlers that
capture necessary exception information and stores the information on
the VCPU and KVM structures.
The following Hyp-ABI is also documented in the code:
Hyp-ABI: Calling HYP-mode functions from host (in SVC mode):
Switching to Hyp mode is done through a simple HVC #0 instruction. The
exception vector code will check that the HVC comes from VMID==0 and if
so will push the necessary state (SPSR, lr_usr) on the Hyp stack.
- r0 contains a pointer to a HYP function
- r1, r2, and r3 contain arguments to the above function.
- The HYP function will be called with its arguments in r0, r1 and r2.
On HYP function return, we return directly to SVC.
A call to a function executing in Hyp mode is performed like the following:
<svc code>
ldr r0, =BSYM(my_hyp_fn)
ldr r1, =my_param
hvc #0 ; Call my_hyp_fn(my_param) from HYP mode
<svc code>
Otherwise, the world-switch is pretty straight-forward. All state that
can be modified by the guest is first backed up on the Hyp stack and the
VCPU values is loaded onto the hardware. State, which is not loaded, but
theoretically modifiable by the guest is protected through the
virtualiation features to generate a trap and cause software emulation.
Upon guest returns, all state is restored from hardware onto the VCPU
struct and the original state is restored from the Hyp-stack onto the
hardware.
SMP support using the VMPIDR calculated on the basis of the host MPIDR
and overriding the low bits with KVM vcpu_id contributed by Marc Zyngier.
Reuse of VMIDs has been implemented by Antonios Motakis and adapated from
a separate patch into the appropriate patches introducing the
functionality. Note that the VMIDs are stored per VM as required by the ARM
architecture reference manual.
To support VFP/NEON we trap those instructions using the HPCTR. When
we trap, we switch the FPU. After a guest exit, the VFP state is
returned to the host. When disabling access to floating point
instructions, we also mask FPEXC_EN in order to avoid the guest
receiving Undefined instruction exceptions before we have a chance to
switch back the floating point state. We are reusing vfp_hard_struct,
so we depend on VFPv3 being enabled in the host kernel, if not, we still
trap cp10 and cp11 in order to inject an undefined instruction exception
whenever the guest tries to use VFP/NEON. VFP/NEON developed by
Antionios Motakis and Rusty Russell.
Aborts that are permission faults, and not stage-1 page table walk, do
not report the faulting address in the HPFAR. We have to resolve the
IPA, and store it just like the HPFAR register on the VCPU struct. If
the IPA cannot be resolved, it means another CPU is playing with the
page tables, and we simply restart the guest. This quirk was fixed by
Marc Zyngier.
Reviewed-by: Will Deacon <will.deacon@arm.com>
Reviewed-by: Marcelo Tosatti <mtosatti@redhat.com>
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Signed-off-by: Antonios Motakis <a.motakis@virtualopensystems.com>
Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
Signed-off-by: Christoffer Dall <c.dall@virtualopensystems.com>
2013-01-21 07:47:42 +08:00
|
|
|
/**
|
|
|
|
* kvm_arch_vcpu_ioctl_run - the main VCPU run function to execute guest code
|
|
|
|
* @vcpu: The VCPU pointer
|
|
|
|
*
|
|
|
|
* This function is called through the VCPU_RUN ioctl called from user space. It
|
|
|
|
* will execute VM code in a loop until the time slice for the process is used
|
|
|
|
* or some emulation is needed from user space in which case the function will
|
|
|
|
* return with return value 0 and with the kvm_run structure filled in with the
|
|
|
|
* required data for the requested emulation.
|
|
|
|
*/
|
2020-04-16 13:10:57 +08:00
|
|
|
int kvm_arch_vcpu_ioctl_run(struct kvm_vcpu *vcpu)
|
2013-01-21 07:28:06 +08:00
|
|
|
{
|
2020-04-16 13:10:57 +08:00
|
|
|
struct kvm_run *run = vcpu->run;
|
KVM: ARM: World-switch implementation
Provides complete world-switch implementation to switch to other guests
running in non-secure modes. Includes Hyp exception handlers that
capture necessary exception information and stores the information on
the VCPU and KVM structures.
The following Hyp-ABI is also documented in the code:
Hyp-ABI: Calling HYP-mode functions from host (in SVC mode):
Switching to Hyp mode is done through a simple HVC #0 instruction. The
exception vector code will check that the HVC comes from VMID==0 and if
so will push the necessary state (SPSR, lr_usr) on the Hyp stack.
- r0 contains a pointer to a HYP function
- r1, r2, and r3 contain arguments to the above function.
- The HYP function will be called with its arguments in r0, r1 and r2.
On HYP function return, we return directly to SVC.
A call to a function executing in Hyp mode is performed like the following:
<svc code>
ldr r0, =BSYM(my_hyp_fn)
ldr r1, =my_param
hvc #0 ; Call my_hyp_fn(my_param) from HYP mode
<svc code>
Otherwise, the world-switch is pretty straight-forward. All state that
can be modified by the guest is first backed up on the Hyp stack and the
VCPU values is loaded onto the hardware. State, which is not loaded, but
theoretically modifiable by the guest is protected through the
virtualiation features to generate a trap and cause software emulation.
Upon guest returns, all state is restored from hardware onto the VCPU
struct and the original state is restored from the Hyp-stack onto the
hardware.
SMP support using the VMPIDR calculated on the basis of the host MPIDR
and overriding the low bits with KVM vcpu_id contributed by Marc Zyngier.
Reuse of VMIDs has been implemented by Antonios Motakis and adapated from
a separate patch into the appropriate patches introducing the
functionality. Note that the VMIDs are stored per VM as required by the ARM
architecture reference manual.
To support VFP/NEON we trap those instructions using the HPCTR. When
we trap, we switch the FPU. After a guest exit, the VFP state is
returned to the host. When disabling access to floating point
instructions, we also mask FPEXC_EN in order to avoid the guest
receiving Undefined instruction exceptions before we have a chance to
switch back the floating point state. We are reusing vfp_hard_struct,
so we depend on VFPv3 being enabled in the host kernel, if not, we still
trap cp10 and cp11 in order to inject an undefined instruction exception
whenever the guest tries to use VFP/NEON. VFP/NEON developed by
Antionios Motakis and Rusty Russell.
Aborts that are permission faults, and not stage-1 page table walk, do
not report the faulting address in the HPFAR. We have to resolve the
IPA, and store it just like the HPFAR register on the VCPU struct. If
the IPA cannot be resolved, it means another CPU is playing with the
page tables, and we simply restart the guest. This quirk was fixed by
Marc Zyngier.
Reviewed-by: Will Deacon <will.deacon@arm.com>
Reviewed-by: Marcelo Tosatti <mtosatti@redhat.com>
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Signed-off-by: Antonios Motakis <a.motakis@virtualopensystems.com>
Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
Signed-off-by: Christoffer Dall <c.dall@virtualopensystems.com>
2013-01-21 07:47:42 +08:00
|
|
|
int ret;
|
|
|
|
|
2013-01-21 07:43:58 +08:00
|
|
|
if (run->exit_reason == KVM_EXIT_MMIO) {
|
2020-06-23 21:14:15 +08:00
|
|
|
ret = kvm_handle_mmio_return(vcpu);
|
2013-01-21 07:43:58 +08:00
|
|
|
if (ret)
|
2017-11-29 23:37:53 +08:00
|
|
|
return ret;
|
2013-01-21 07:43:58 +08:00
|
|
|
}
|
|
|
|
|
2017-11-29 23:37:53 +08:00
|
|
|
vcpu_load(vcpu);
|
2017-02-08 18:50:15 +08:00
|
|
|
|
2021-05-26 22:18:31 +08:00
|
|
|
if (run->immediate_exit) {
|
|
|
|
ret = -EINTR;
|
|
|
|
goto out;
|
|
|
|
}
|
|
|
|
|
2017-11-25 05:39:01 +08:00
|
|
|
kvm_sigset_activate(vcpu);
|
KVM: ARM: World-switch implementation
Provides complete world-switch implementation to switch to other guests
running in non-secure modes. Includes Hyp exception handlers that
capture necessary exception information and stores the information on
the VCPU and KVM structures.
The following Hyp-ABI is also documented in the code:
Hyp-ABI: Calling HYP-mode functions from host (in SVC mode):
Switching to Hyp mode is done through a simple HVC #0 instruction. The
exception vector code will check that the HVC comes from VMID==0 and if
so will push the necessary state (SPSR, lr_usr) on the Hyp stack.
- r0 contains a pointer to a HYP function
- r1, r2, and r3 contain arguments to the above function.
- The HYP function will be called with its arguments in r0, r1 and r2.
On HYP function return, we return directly to SVC.
A call to a function executing in Hyp mode is performed like the following:
<svc code>
ldr r0, =BSYM(my_hyp_fn)
ldr r1, =my_param
hvc #0 ; Call my_hyp_fn(my_param) from HYP mode
<svc code>
Otherwise, the world-switch is pretty straight-forward. All state that
can be modified by the guest is first backed up on the Hyp stack and the
VCPU values is loaded onto the hardware. State, which is not loaded, but
theoretically modifiable by the guest is protected through the
virtualiation features to generate a trap and cause software emulation.
Upon guest returns, all state is restored from hardware onto the VCPU
struct and the original state is restored from the Hyp-stack onto the
hardware.
SMP support using the VMPIDR calculated on the basis of the host MPIDR
and overriding the low bits with KVM vcpu_id contributed by Marc Zyngier.
Reuse of VMIDs has been implemented by Antonios Motakis and adapated from
a separate patch into the appropriate patches introducing the
functionality. Note that the VMIDs are stored per VM as required by the ARM
architecture reference manual.
To support VFP/NEON we trap those instructions using the HPCTR. When
we trap, we switch the FPU. After a guest exit, the VFP state is
returned to the host. When disabling access to floating point
instructions, we also mask FPEXC_EN in order to avoid the guest
receiving Undefined instruction exceptions before we have a chance to
switch back the floating point state. We are reusing vfp_hard_struct,
so we depend on VFPv3 being enabled in the host kernel, if not, we still
trap cp10 and cp11 in order to inject an undefined instruction exception
whenever the guest tries to use VFP/NEON. VFP/NEON developed by
Antionios Motakis and Rusty Russell.
Aborts that are permission faults, and not stage-1 page table walk, do
not report the faulting address in the HPFAR. We have to resolve the
IPA, and store it just like the HPFAR register on the VCPU struct. If
the IPA cannot be resolved, it means another CPU is playing with the
page tables, and we simply restart the guest. This quirk was fixed by
Marc Zyngier.
Reviewed-by: Will Deacon <will.deacon@arm.com>
Reviewed-by: Marcelo Tosatti <mtosatti@redhat.com>
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Signed-off-by: Antonios Motakis <a.motakis@virtualopensystems.com>
Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
Signed-off-by: Christoffer Dall <c.dall@virtualopensystems.com>
2013-01-21 07:47:42 +08:00
|
|
|
|
|
|
|
ret = 1;
|
|
|
|
run->exit_reason = KVM_EXIT_UNKNOWN;
|
KVM: arm64: uapi: Add kvm_debug_exit_arch.hsr_high
When userspace is debugging a VM, the kvm_debug_exit_arch part of the
kvm_run struct contains arm64 specific debug information: the ESR_EL2
value, encoded in the field "hsr", and the address of the instruction
that caused the exception, encoded in the field "far".
Linux has moved to treating ESR_EL2 as a 64-bit register, but unfortunately
kvm_debug_exit_arch.hsr cannot be changed because that would change the
memory layout of the struct on big endian machines:
Current layout: | Layout with "hsr" extended to 64 bits:
|
offset 0: ESR_EL2[31:0] (hsr) | offset 0: ESR_EL2[61:32] (hsr[61:32])
offset 4: padding | offset 4: ESR_EL2[31:0] (hsr[31:0])
offset 8: FAR_EL2[61:0] (far) | offset 8: FAR_EL2[61:0] (far)
which breaks existing code.
The padding is inserted by the compiler because the "far" field must be
aligned to 8 bytes (each field must be naturally aligned - aapcs64 [1],
page 18), and the struct itself must be aligned to 8 bytes (the struct must
be aligned to the maximum alignment of its fields - aapcs64, page 18),
which means that "hsr" must be aligned to 8 bytes as it is the first field
in the struct.
To avoid changing the struct size and layout for the existing fields, add a
new field, "hsr_high", which replaces the existing padding. "hsr_high" will
be used to hold the ESR_EL2[61:32] bits of the register. The memory layout,
both on big and little endian machine, becomes:
offset 0: ESR_EL2[31:0] (hsr)
offset 4: ESR_EL2[61:32] (hsr_high)
offset 8: FAR_EL2[61:0] (far)
The padding that the compiler inserts for the current struct layout is
unitialized. To prevent an updated userspace running on an old kernel
mistaking the padding for a valid "hsr_high" value, add a new flag,
KVM_DEBUG_ARCH_HSR_HIGH_VALID, to kvm_run->flags to let userspace know that
"hsr_high" holds a valid ESR_EL2[61:32] value.
[1] https://github.com/ARM-software/abi-aa/releases/download/2021Q3/aapcs64.pdf
Signed-off-by: Alexandru Elisei <alexandru.elisei@arm.com>
Reviewed-by: Marc Zyngier <maz@kernel.org>
Link: https://lore.kernel.org/r/20220425114444.368693-6-alexandru.elisei@arm.com
Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
2022-04-25 19:44:44 +08:00
|
|
|
run->flags = 0;
|
KVM: ARM: World-switch implementation
Provides complete world-switch implementation to switch to other guests
running in non-secure modes. Includes Hyp exception handlers that
capture necessary exception information and stores the information on
the VCPU and KVM structures.
The following Hyp-ABI is also documented in the code:
Hyp-ABI: Calling HYP-mode functions from host (in SVC mode):
Switching to Hyp mode is done through a simple HVC #0 instruction. The
exception vector code will check that the HVC comes from VMID==0 and if
so will push the necessary state (SPSR, lr_usr) on the Hyp stack.
- r0 contains a pointer to a HYP function
- r1, r2, and r3 contain arguments to the above function.
- The HYP function will be called with its arguments in r0, r1 and r2.
On HYP function return, we return directly to SVC.
A call to a function executing in Hyp mode is performed like the following:
<svc code>
ldr r0, =BSYM(my_hyp_fn)
ldr r1, =my_param
hvc #0 ; Call my_hyp_fn(my_param) from HYP mode
<svc code>
Otherwise, the world-switch is pretty straight-forward. All state that
can be modified by the guest is first backed up on the Hyp stack and the
VCPU values is loaded onto the hardware. State, which is not loaded, but
theoretically modifiable by the guest is protected through the
virtualiation features to generate a trap and cause software emulation.
Upon guest returns, all state is restored from hardware onto the VCPU
struct and the original state is restored from the Hyp-stack onto the
hardware.
SMP support using the VMPIDR calculated on the basis of the host MPIDR
and overriding the low bits with KVM vcpu_id contributed by Marc Zyngier.
Reuse of VMIDs has been implemented by Antonios Motakis and adapated from
a separate patch into the appropriate patches introducing the
functionality. Note that the VMIDs are stored per VM as required by the ARM
architecture reference manual.
To support VFP/NEON we trap those instructions using the HPCTR. When
we trap, we switch the FPU. After a guest exit, the VFP state is
returned to the host. When disabling access to floating point
instructions, we also mask FPEXC_EN in order to avoid the guest
receiving Undefined instruction exceptions before we have a chance to
switch back the floating point state. We are reusing vfp_hard_struct,
so we depend on VFPv3 being enabled in the host kernel, if not, we still
trap cp10 and cp11 in order to inject an undefined instruction exception
whenever the guest tries to use VFP/NEON. VFP/NEON developed by
Antionios Motakis and Rusty Russell.
Aborts that are permission faults, and not stage-1 page table walk, do
not report the faulting address in the HPFAR. We have to resolve the
IPA, and store it just like the HPFAR register on the VCPU struct. If
the IPA cannot be resolved, it means another CPU is playing with the
page tables, and we simply restart the guest. This quirk was fixed by
Marc Zyngier.
Reviewed-by: Will Deacon <will.deacon@arm.com>
Reviewed-by: Marcelo Tosatti <mtosatti@redhat.com>
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Signed-off-by: Antonios Motakis <a.motakis@virtualopensystems.com>
Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
Signed-off-by: Christoffer Dall <c.dall@virtualopensystems.com>
2013-01-21 07:47:42 +08:00
|
|
|
while (ret > 0) {
|
|
|
|
/*
|
|
|
|
* Check conditions before entering the guest
|
|
|
|
*/
|
2021-08-03 03:28:09 +08:00
|
|
|
ret = xfer_to_guest_mode_handle_work(vcpu);
|
|
|
|
if (!ret)
|
|
|
|
ret = 1;
|
KVM: ARM: World-switch implementation
Provides complete world-switch implementation to switch to other guests
running in non-secure modes. Includes Hyp exception handlers that
capture necessary exception information and stores the information on
the VCPU and KVM structures.
The following Hyp-ABI is also documented in the code:
Hyp-ABI: Calling HYP-mode functions from host (in SVC mode):
Switching to Hyp mode is done through a simple HVC #0 instruction. The
exception vector code will check that the HVC comes from VMID==0 and if
so will push the necessary state (SPSR, lr_usr) on the Hyp stack.
- r0 contains a pointer to a HYP function
- r1, r2, and r3 contain arguments to the above function.
- The HYP function will be called with its arguments in r0, r1 and r2.
On HYP function return, we return directly to SVC.
A call to a function executing in Hyp mode is performed like the following:
<svc code>
ldr r0, =BSYM(my_hyp_fn)
ldr r1, =my_param
hvc #0 ; Call my_hyp_fn(my_param) from HYP mode
<svc code>
Otherwise, the world-switch is pretty straight-forward. All state that
can be modified by the guest is first backed up on the Hyp stack and the
VCPU values is loaded onto the hardware. State, which is not loaded, but
theoretically modifiable by the guest is protected through the
virtualiation features to generate a trap and cause software emulation.
Upon guest returns, all state is restored from hardware onto the VCPU
struct and the original state is restored from the Hyp-stack onto the
hardware.
SMP support using the VMPIDR calculated on the basis of the host MPIDR
and overriding the low bits with KVM vcpu_id contributed by Marc Zyngier.
Reuse of VMIDs has been implemented by Antonios Motakis and adapated from
a separate patch into the appropriate patches introducing the
functionality. Note that the VMIDs are stored per VM as required by the ARM
architecture reference manual.
To support VFP/NEON we trap those instructions using the HPCTR. When
we trap, we switch the FPU. After a guest exit, the VFP state is
returned to the host. When disabling access to floating point
instructions, we also mask FPEXC_EN in order to avoid the guest
receiving Undefined instruction exceptions before we have a chance to
switch back the floating point state. We are reusing vfp_hard_struct,
so we depend on VFPv3 being enabled in the host kernel, if not, we still
trap cp10 and cp11 in order to inject an undefined instruction exception
whenever the guest tries to use VFP/NEON. VFP/NEON developed by
Antionios Motakis and Rusty Russell.
Aborts that are permission faults, and not stage-1 page table walk, do
not report the faulting address in the HPFAR. We have to resolve the
IPA, and store it just like the HPFAR register on the VCPU struct. If
the IPA cannot be resolved, it means another CPU is playing with the
page tables, and we simply restart the guest. This quirk was fixed by
Marc Zyngier.
Reviewed-by: Will Deacon <will.deacon@arm.com>
Reviewed-by: Marcelo Tosatti <mtosatti@redhat.com>
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Signed-off-by: Antonios Motakis <a.motakis@virtualopensystems.com>
Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
Signed-off-by: Christoffer Dall <c.dall@virtualopensystems.com>
2013-01-21 07:47:42 +08:00
|
|
|
|
2022-05-04 11:24:39 +08:00
|
|
|
if (ret > 0)
|
|
|
|
ret = check_vcpu_requests(vcpu);
|
2017-06-04 20:43:55 +08:00
|
|
|
|
2015-06-08 22:00:28 +08:00
|
|
|
/*
|
|
|
|
* Preparing the interrupts to be injected also
|
|
|
|
* involves poking the GIC, which must be done in a
|
|
|
|
* non-preemptible context.
|
|
|
|
*/
|
2015-05-29 02:49:10 +08:00
|
|
|
preempt_disable();
|
2016-03-24 18:21:04 +08:00
|
|
|
|
2021-11-22 20:18:43 +08:00
|
|
|
/*
|
|
|
|
* The VMID allocator only tracks active VMIDs per
|
|
|
|
* physical CPU, and therefore the VMID allocated may not be
|
|
|
|
* preserved on VMID roll-over if the task was preempted,
|
|
|
|
* making a thread's VMID inactive. So we need to call
|
|
|
|
* kvm_arm_vmid_update() in non-premptible context.
|
|
|
|
*/
|
|
|
|
kvm_arm_vmid_update(&vcpu->arch.hw_mmu->vmid);
|
|
|
|
|
2016-02-26 19:29:19 +08:00
|
|
|
kvm_pmu_flush_hwstate(vcpu);
|
2016-03-24 18:21:04 +08:00
|
|
|
|
KVM: ARM: World-switch implementation
Provides complete world-switch implementation to switch to other guests
running in non-secure modes. Includes Hyp exception handlers that
capture necessary exception information and stores the information on
the VCPU and KVM structures.
The following Hyp-ABI is also documented in the code:
Hyp-ABI: Calling HYP-mode functions from host (in SVC mode):
Switching to Hyp mode is done through a simple HVC #0 instruction. The
exception vector code will check that the HVC comes from VMID==0 and if
so will push the necessary state (SPSR, lr_usr) on the Hyp stack.
- r0 contains a pointer to a HYP function
- r1, r2, and r3 contain arguments to the above function.
- The HYP function will be called with its arguments in r0, r1 and r2.
On HYP function return, we return directly to SVC.
A call to a function executing in Hyp mode is performed like the following:
<svc code>
ldr r0, =BSYM(my_hyp_fn)
ldr r1, =my_param
hvc #0 ; Call my_hyp_fn(my_param) from HYP mode
<svc code>
Otherwise, the world-switch is pretty straight-forward. All state that
can be modified by the guest is first backed up on the Hyp stack and the
VCPU values is loaded onto the hardware. State, which is not loaded, but
theoretically modifiable by the guest is protected through the
virtualiation features to generate a trap and cause software emulation.
Upon guest returns, all state is restored from hardware onto the VCPU
struct and the original state is restored from the Hyp-stack onto the
hardware.
SMP support using the VMPIDR calculated on the basis of the host MPIDR
and overriding the low bits with KVM vcpu_id contributed by Marc Zyngier.
Reuse of VMIDs has been implemented by Antonios Motakis and adapated from
a separate patch into the appropriate patches introducing the
functionality. Note that the VMIDs are stored per VM as required by the ARM
architecture reference manual.
To support VFP/NEON we trap those instructions using the HPCTR. When
we trap, we switch the FPU. After a guest exit, the VFP state is
returned to the host. When disabling access to floating point
instructions, we also mask FPEXC_EN in order to avoid the guest
receiving Undefined instruction exceptions before we have a chance to
switch back the floating point state. We are reusing vfp_hard_struct,
so we depend on VFPv3 being enabled in the host kernel, if not, we still
trap cp10 and cp11 in order to inject an undefined instruction exception
whenever the guest tries to use VFP/NEON. VFP/NEON developed by
Antionios Motakis and Rusty Russell.
Aborts that are permission faults, and not stage-1 page table walk, do
not report the faulting address in the HPFAR. We have to resolve the
IPA, and store it just like the HPFAR register on the VCPU struct. If
the IPA cannot be resolved, it means another CPU is playing with the
page tables, and we simply restart the guest. This quirk was fixed by
Marc Zyngier.
Reviewed-by: Will Deacon <will.deacon@arm.com>
Reviewed-by: Marcelo Tosatti <mtosatti@redhat.com>
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Signed-off-by: Antonios Motakis <a.motakis@virtualopensystems.com>
Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
Signed-off-by: Christoffer Dall <c.dall@virtualopensystems.com>
2013-01-21 07:47:42 +08:00
|
|
|
local_irq_disable();
|
|
|
|
|
2015-06-08 22:00:28 +08:00
|
|
|
kvm_vgic_flush_hwstate(vcpu);
|
|
|
|
|
2022-05-10 17:57:09 +08:00
|
|
|
kvm_pmu_update_vcpu_events(vcpu);
|
|
|
|
|
2017-06-04 20:43:54 +08:00
|
|
|
/*
|
|
|
|
* Ensure we set mode to IN_GUEST_MODE after we disable
|
|
|
|
* interrupts and before the final VCPU requests check.
|
|
|
|
* See the comment in kvm_vcpu_exiting_guest_mode() and
|
2019-07-24 15:24:49 +08:00
|
|
|
* Documentation/virt/kvm/vcpu-requests.rst
|
2017-06-04 20:43:54 +08:00
|
|
|
*/
|
|
|
|
smp_store_mb(vcpu->mode, IN_GUEST_MODE);
|
|
|
|
|
2021-08-03 03:28:09 +08:00
|
|
|
if (ret <= 0 || kvm_vcpu_exit_request(vcpu, &ret)) {
|
2017-06-04 20:43:54 +08:00
|
|
|
vcpu->mode = OUTSIDE_GUEST_MODE;
|
2017-10-05 05:42:32 +08:00
|
|
|
isb(); /* Ensure work in x_flush_hwstate is committed */
|
2016-02-26 19:29:19 +08:00
|
|
|
kvm_pmu_sync_hwstate(vcpu);
|
2017-10-28 01:57:51 +08:00
|
|
|
if (static_branch_unlikely(&userspace_irqchip_in_use))
|
2020-04-22 15:58:22 +08:00
|
|
|
kvm_timer_sync_user(vcpu);
|
2013-01-22 08:36:12 +08:00
|
|
|
kvm_vgic_sync_hwstate(vcpu);
|
2016-10-17 02:24:30 +08:00
|
|
|
local_irq_enable();
|
2015-06-08 22:00:28 +08:00
|
|
|
preempt_enable();
|
KVM: ARM: World-switch implementation
Provides complete world-switch implementation to switch to other guests
running in non-secure modes. Includes Hyp exception handlers that
capture necessary exception information and stores the information on
the VCPU and KVM structures.
The following Hyp-ABI is also documented in the code:
Hyp-ABI: Calling HYP-mode functions from host (in SVC mode):
Switching to Hyp mode is done through a simple HVC #0 instruction. The
exception vector code will check that the HVC comes from VMID==0 and if
so will push the necessary state (SPSR, lr_usr) on the Hyp stack.
- r0 contains a pointer to a HYP function
- r1, r2, and r3 contain arguments to the above function.
- The HYP function will be called with its arguments in r0, r1 and r2.
On HYP function return, we return directly to SVC.
A call to a function executing in Hyp mode is performed like the following:
<svc code>
ldr r0, =BSYM(my_hyp_fn)
ldr r1, =my_param
hvc #0 ; Call my_hyp_fn(my_param) from HYP mode
<svc code>
Otherwise, the world-switch is pretty straight-forward. All state that
can be modified by the guest is first backed up on the Hyp stack and the
VCPU values is loaded onto the hardware. State, which is not loaded, but
theoretically modifiable by the guest is protected through the
virtualiation features to generate a trap and cause software emulation.
Upon guest returns, all state is restored from hardware onto the VCPU
struct and the original state is restored from the Hyp-stack onto the
hardware.
SMP support using the VMPIDR calculated on the basis of the host MPIDR
and overriding the low bits with KVM vcpu_id contributed by Marc Zyngier.
Reuse of VMIDs has been implemented by Antonios Motakis and adapated from
a separate patch into the appropriate patches introducing the
functionality. Note that the VMIDs are stored per VM as required by the ARM
architecture reference manual.
To support VFP/NEON we trap those instructions using the HPCTR. When
we trap, we switch the FPU. After a guest exit, the VFP state is
returned to the host. When disabling access to floating point
instructions, we also mask FPEXC_EN in order to avoid the guest
receiving Undefined instruction exceptions before we have a chance to
switch back the floating point state. We are reusing vfp_hard_struct,
so we depend on VFPv3 being enabled in the host kernel, if not, we still
trap cp10 and cp11 in order to inject an undefined instruction exception
whenever the guest tries to use VFP/NEON. VFP/NEON developed by
Antionios Motakis and Rusty Russell.
Aborts that are permission faults, and not stage-1 page table walk, do
not report the faulting address in the HPFAR. We have to resolve the
IPA, and store it just like the HPFAR register on the VCPU struct. If
the IPA cannot be resolved, it means another CPU is playing with the
page tables, and we simply restart the guest. This quirk was fixed by
Marc Zyngier.
Reviewed-by: Will Deacon <will.deacon@arm.com>
Reviewed-by: Marcelo Tosatti <mtosatti@redhat.com>
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Signed-off-by: Antonios Motakis <a.motakis@virtualopensystems.com>
Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
Signed-off-by: Christoffer Dall <c.dall@virtualopensystems.com>
2013-01-21 07:47:42 +08:00
|
|
|
continue;
|
|
|
|
}
|
|
|
|
|
2015-07-08 00:29:56 +08:00
|
|
|
kvm_arm_setup_debug(vcpu);
|
2021-10-21 21:10:35 +08:00
|
|
|
kvm_arch_vcpu_ctxflush_fp(vcpu);
|
2015-07-08 00:29:56 +08:00
|
|
|
|
KVM: ARM: World-switch implementation
Provides complete world-switch implementation to switch to other guests
running in non-secure modes. Includes Hyp exception handlers that
capture necessary exception information and stores the information on
the VCPU and KVM structures.
The following Hyp-ABI is also documented in the code:
Hyp-ABI: Calling HYP-mode functions from host (in SVC mode):
Switching to Hyp mode is done through a simple HVC #0 instruction. The
exception vector code will check that the HVC comes from VMID==0 and if
so will push the necessary state (SPSR, lr_usr) on the Hyp stack.
- r0 contains a pointer to a HYP function
- r1, r2, and r3 contain arguments to the above function.
- The HYP function will be called with its arguments in r0, r1 and r2.
On HYP function return, we return directly to SVC.
A call to a function executing in Hyp mode is performed like the following:
<svc code>
ldr r0, =BSYM(my_hyp_fn)
ldr r1, =my_param
hvc #0 ; Call my_hyp_fn(my_param) from HYP mode
<svc code>
Otherwise, the world-switch is pretty straight-forward. All state that
can be modified by the guest is first backed up on the Hyp stack and the
VCPU values is loaded onto the hardware. State, which is not loaded, but
theoretically modifiable by the guest is protected through the
virtualiation features to generate a trap and cause software emulation.
Upon guest returns, all state is restored from hardware onto the VCPU
struct and the original state is restored from the Hyp-stack onto the
hardware.
SMP support using the VMPIDR calculated on the basis of the host MPIDR
and overriding the low bits with KVM vcpu_id contributed by Marc Zyngier.
Reuse of VMIDs has been implemented by Antonios Motakis and adapated from
a separate patch into the appropriate patches introducing the
functionality. Note that the VMIDs are stored per VM as required by the ARM
architecture reference manual.
To support VFP/NEON we trap those instructions using the HPCTR. When
we trap, we switch the FPU. After a guest exit, the VFP state is
returned to the host. When disabling access to floating point
instructions, we also mask FPEXC_EN in order to avoid the guest
receiving Undefined instruction exceptions before we have a chance to
switch back the floating point state. We are reusing vfp_hard_struct,
so we depend on VFPv3 being enabled in the host kernel, if not, we still
trap cp10 and cp11 in order to inject an undefined instruction exception
whenever the guest tries to use VFP/NEON. VFP/NEON developed by
Antionios Motakis and Rusty Russell.
Aborts that are permission faults, and not stage-1 page table walk, do
not report the faulting address in the HPFAR. We have to resolve the
IPA, and store it just like the HPFAR register on the VCPU struct. If
the IPA cannot be resolved, it means another CPU is playing with the
page tables, and we simply restart the guest. This quirk was fixed by
Marc Zyngier.
Reviewed-by: Will Deacon <will.deacon@arm.com>
Reviewed-by: Marcelo Tosatti <mtosatti@redhat.com>
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Signed-off-by: Antonios Motakis <a.motakis@virtualopensystems.com>
Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
Signed-off-by: Christoffer Dall <c.dall@virtualopensystems.com>
2013-01-21 07:47:42 +08:00
|
|
|
/**************************************************************
|
|
|
|
* Enter the guest
|
|
|
|
*/
|
|
|
|
trace_kvm_entry(*vcpu_pc(vcpu));
|
2022-02-01 21:29:23 +08:00
|
|
|
guest_timing_enter_irqoff();
|
KVM: ARM: World-switch implementation
Provides complete world-switch implementation to switch to other guests
running in non-secure modes. Includes Hyp exception handlers that
capture necessary exception information and stores the information on
the VCPU and KVM structures.
The following Hyp-ABI is also documented in the code:
Hyp-ABI: Calling HYP-mode functions from host (in SVC mode):
Switching to Hyp mode is done through a simple HVC #0 instruction. The
exception vector code will check that the HVC comes from VMID==0 and if
so will push the necessary state (SPSR, lr_usr) on the Hyp stack.
- r0 contains a pointer to a HYP function
- r1, r2, and r3 contain arguments to the above function.
- The HYP function will be called with its arguments in r0, r1 and r2.
On HYP function return, we return directly to SVC.
A call to a function executing in Hyp mode is performed like the following:
<svc code>
ldr r0, =BSYM(my_hyp_fn)
ldr r1, =my_param
hvc #0 ; Call my_hyp_fn(my_param) from HYP mode
<svc code>
Otherwise, the world-switch is pretty straight-forward. All state that
can be modified by the guest is first backed up on the Hyp stack and the
VCPU values is loaded onto the hardware. State, which is not loaded, but
theoretically modifiable by the guest is protected through the
virtualiation features to generate a trap and cause software emulation.
Upon guest returns, all state is restored from hardware onto the VCPU
struct and the original state is restored from the Hyp-stack onto the
hardware.
SMP support using the VMPIDR calculated on the basis of the host MPIDR
and overriding the low bits with KVM vcpu_id contributed by Marc Zyngier.
Reuse of VMIDs has been implemented by Antonios Motakis and adapated from
a separate patch into the appropriate patches introducing the
functionality. Note that the VMIDs are stored per VM as required by the ARM
architecture reference manual.
To support VFP/NEON we trap those instructions using the HPCTR. When
we trap, we switch the FPU. After a guest exit, the VFP state is
returned to the host. When disabling access to floating point
instructions, we also mask FPEXC_EN in order to avoid the guest
receiving Undefined instruction exceptions before we have a chance to
switch back the floating point state. We are reusing vfp_hard_struct,
so we depend on VFPv3 being enabled in the host kernel, if not, we still
trap cp10 and cp11 in order to inject an undefined instruction exception
whenever the guest tries to use VFP/NEON. VFP/NEON developed by
Antionios Motakis and Rusty Russell.
Aborts that are permission faults, and not stage-1 page table walk, do
not report the faulting address in the HPFAR. We have to resolve the
IPA, and store it just like the HPFAR register on the VCPU struct. If
the IPA cannot be resolved, it means another CPU is playing with the
page tables, and we simply restart the guest. This quirk was fixed by
Marc Zyngier.
Reviewed-by: Will Deacon <will.deacon@arm.com>
Reviewed-by: Marcelo Tosatti <mtosatti@redhat.com>
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Signed-off-by: Antonios Motakis <a.motakis@virtualopensystems.com>
Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
Signed-off-by: Christoffer Dall <c.dall@virtualopensystems.com>
2013-01-21 07:47:42 +08:00
|
|
|
|
2022-02-01 21:29:23 +08:00
|
|
|
ret = kvm_arm_vcpu_enter_exit(vcpu);
|
2017-10-03 20:02:12 +08:00
|
|
|
|
KVM: ARM: World-switch implementation
Provides complete world-switch implementation to switch to other guests
running in non-secure modes. Includes Hyp exception handlers that
capture necessary exception information and stores the information on
the VCPU and KVM structures.
The following Hyp-ABI is also documented in the code:
Hyp-ABI: Calling HYP-mode functions from host (in SVC mode):
Switching to Hyp mode is done through a simple HVC #0 instruction. The
exception vector code will check that the HVC comes from VMID==0 and if
so will push the necessary state (SPSR, lr_usr) on the Hyp stack.
- r0 contains a pointer to a HYP function
- r1, r2, and r3 contain arguments to the above function.
- The HYP function will be called with its arguments in r0, r1 and r2.
On HYP function return, we return directly to SVC.
A call to a function executing in Hyp mode is performed like the following:
<svc code>
ldr r0, =BSYM(my_hyp_fn)
ldr r1, =my_param
hvc #0 ; Call my_hyp_fn(my_param) from HYP mode
<svc code>
Otherwise, the world-switch is pretty straight-forward. All state that
can be modified by the guest is first backed up on the Hyp stack and the
VCPU values is loaded onto the hardware. State, which is not loaded, but
theoretically modifiable by the guest is protected through the
virtualiation features to generate a trap and cause software emulation.
Upon guest returns, all state is restored from hardware onto the VCPU
struct and the original state is restored from the Hyp-stack onto the
hardware.
SMP support using the VMPIDR calculated on the basis of the host MPIDR
and overriding the low bits with KVM vcpu_id contributed by Marc Zyngier.
Reuse of VMIDs has been implemented by Antonios Motakis and adapated from
a separate patch into the appropriate patches introducing the
functionality. Note that the VMIDs are stored per VM as required by the ARM
architecture reference manual.
To support VFP/NEON we trap those instructions using the HPCTR. When
we trap, we switch the FPU. After a guest exit, the VFP state is
returned to the host. When disabling access to floating point
instructions, we also mask FPEXC_EN in order to avoid the guest
receiving Undefined instruction exceptions before we have a chance to
switch back the floating point state. We are reusing vfp_hard_struct,
so we depend on VFPv3 being enabled in the host kernel, if not, we still
trap cp10 and cp11 in order to inject an undefined instruction exception
whenever the guest tries to use VFP/NEON. VFP/NEON developed by
Antionios Motakis and Rusty Russell.
Aborts that are permission faults, and not stage-1 page table walk, do
not report the faulting address in the HPFAR. We have to resolve the
IPA, and store it just like the HPFAR register on the VCPU struct. If
the IPA cannot be resolved, it means another CPU is playing with the
page tables, and we simply restart the guest. This quirk was fixed by
Marc Zyngier.
Reviewed-by: Will Deacon <will.deacon@arm.com>
Reviewed-by: Marcelo Tosatti <mtosatti@redhat.com>
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Signed-off-by: Antonios Motakis <a.motakis@virtualopensystems.com>
Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
Signed-off-by: Christoffer Dall <c.dall@virtualopensystems.com>
2013-01-21 07:47:42 +08:00
|
|
|
vcpu->mode = OUTSIDE_GUEST_MODE;
|
2015-11-26 18:09:43 +08:00
|
|
|
vcpu->stat.exits++;
|
2015-05-29 02:49:10 +08:00
|
|
|
/*
|
|
|
|
* Back from guest
|
|
|
|
*************************************************************/
|
|
|
|
|
2015-07-08 00:29:56 +08:00
|
|
|
kvm_arm_clear_debug(vcpu);
|
|
|
|
|
2016-10-17 02:24:30 +08:00
|
|
|
/*
|
KVM: arm/arm64: Avoid timer save/restore in vcpu entry/exit
We don't need to save and restore the hardware timer state and examine
if it generates interrupts on on every entry/exit to the guest. The
timer hardware is perfectly capable of telling us when it has expired
by signaling interrupts.
When taking a vtimer interrupt in the host, we don't want to mess with
the timer configuration, we just want to forward the physical interrupt
to the guest as a virtual interrupt. We can use the split priority drop
and deactivate feature of the GIC to do this, which leaves an EOI'ed
interrupt active on the physical distributor, making sure we don't keep
taking timer interrupts which would prevent the guest from running. We
can then forward the physical interrupt to the VM using the HW bit in
the LR of the GIC, like we do already, which lets the guest directly
deactivate both the physical and virtual timer simultaneously, allowing
the timer hardware to exit the VM and generate a new physical interrupt
when the timer output is again asserted later on.
We do need to capture this state when migrating VCPUs between physical
CPUs, however, which we use the vcpu put/load functions for, which are
called through preempt notifiers whenever the thread is scheduled away
from the CPU or called directly if we return from the ioctl to
userspace.
One caveat is that we have to save and restore the timer state in both
kvm_timer_vcpu_[put/load] and kvm_timer_[schedule/unschedule], because
we can have the following flows:
1. kvm_vcpu_block
2. kvm_timer_schedule
3. schedule
4. kvm_timer_vcpu_put (preempt notifier)
5. schedule (vcpu thread gets scheduled back)
6. kvm_timer_vcpu_load (preempt notifier)
7. kvm_timer_unschedule
And a version where we don't actually call schedule:
1. kvm_vcpu_block
2. kvm_timer_schedule
7. kvm_timer_unschedule
Since kvm_timer_[schedule/unschedule] may not be followed by put/load,
but put/load also may be called independently, we call the timer
save/restore functions from both paths. Since they rely on the loaded
flag to never save/restore when unnecessary, this doesn't cause any
harm, and we ensure that all invokations of either set of functions work
as intended.
An added benefit beyond not having to read and write the timer sysregs
on every entry and exit is that we no longer have to actively write the
active state to the physical distributor, because we configured the
irq for the vtimer to only get a priority drop when handling the
interrupt in the GIC driver (we called irq_set_vcpu_affinity()), and
the interrupt stays active after firing on the host.
Reviewed-by: Marc Zyngier <marc.zyngier@arm.com>
Signed-off-by: Christoffer Dall <cdall@linaro.org>
2016-10-17 02:30:38 +08:00
|
|
|
* We must sync the PMU state before the vgic state so
|
2016-10-17 02:24:30 +08:00
|
|
|
* that the vgic can properly sample the updated state of the
|
|
|
|
* interrupt line.
|
|
|
|
*/
|
|
|
|
kvm_pmu_sync_hwstate(vcpu);
|
|
|
|
|
KVM: arm/arm64: Avoid timer save/restore in vcpu entry/exit
We don't need to save and restore the hardware timer state and examine
if it generates interrupts on on every entry/exit to the guest. The
timer hardware is perfectly capable of telling us when it has expired
by signaling interrupts.
When taking a vtimer interrupt in the host, we don't want to mess with
the timer configuration, we just want to forward the physical interrupt
to the guest as a virtual interrupt. We can use the split priority drop
and deactivate feature of the GIC to do this, which leaves an EOI'ed
interrupt active on the physical distributor, making sure we don't keep
taking timer interrupts which would prevent the guest from running. We
can then forward the physical interrupt to the VM using the HW bit in
the LR of the GIC, like we do already, which lets the guest directly
deactivate both the physical and virtual timer simultaneously, allowing
the timer hardware to exit the VM and generate a new physical interrupt
when the timer output is again asserted later on.
We do need to capture this state when migrating VCPUs between physical
CPUs, however, which we use the vcpu put/load functions for, which are
called through preempt notifiers whenever the thread is scheduled away
from the CPU or called directly if we return from the ioctl to
userspace.
One caveat is that we have to save and restore the timer state in both
kvm_timer_vcpu_[put/load] and kvm_timer_[schedule/unschedule], because
we can have the following flows:
1. kvm_vcpu_block
2. kvm_timer_schedule
3. schedule
4. kvm_timer_vcpu_put (preempt notifier)
5. schedule (vcpu thread gets scheduled back)
6. kvm_timer_vcpu_load (preempt notifier)
7. kvm_timer_unschedule
And a version where we don't actually call schedule:
1. kvm_vcpu_block
2. kvm_timer_schedule
7. kvm_timer_unschedule
Since kvm_timer_[schedule/unschedule] may not be followed by put/load,
but put/load also may be called independently, we call the timer
save/restore functions from both paths. Since they rely on the loaded
flag to never save/restore when unnecessary, this doesn't cause any
harm, and we ensure that all invokations of either set of functions work
as intended.
An added benefit beyond not having to read and write the timer sysregs
on every entry and exit is that we no longer have to actively write the
active state to the physical distributor, because we configured the
irq for the vtimer to only get a priority drop when handling the
interrupt in the GIC driver (we called irq_set_vcpu_affinity()), and
the interrupt stays active after firing on the host.
Reviewed-by: Marc Zyngier <marc.zyngier@arm.com>
Signed-off-by: Christoffer Dall <cdall@linaro.org>
2016-10-17 02:30:38 +08:00
|
|
|
/*
|
|
|
|
* Sync the vgic state before syncing the timer state because
|
|
|
|
* the timer code needs to know if the virtual timer
|
|
|
|
* interrupts are active.
|
|
|
|
*/
|
2016-10-17 02:24:30 +08:00
|
|
|
kvm_vgic_sync_hwstate(vcpu);
|
|
|
|
|
KVM: arm/arm64: Avoid timer save/restore in vcpu entry/exit
We don't need to save and restore the hardware timer state and examine
if it generates interrupts on on every entry/exit to the guest. The
timer hardware is perfectly capable of telling us when it has expired
by signaling interrupts.
When taking a vtimer interrupt in the host, we don't want to mess with
the timer configuration, we just want to forward the physical interrupt
to the guest as a virtual interrupt. We can use the split priority drop
and deactivate feature of the GIC to do this, which leaves an EOI'ed
interrupt active on the physical distributor, making sure we don't keep
taking timer interrupts which would prevent the guest from running. We
can then forward the physical interrupt to the VM using the HW bit in
the LR of the GIC, like we do already, which lets the guest directly
deactivate both the physical and virtual timer simultaneously, allowing
the timer hardware to exit the VM and generate a new physical interrupt
when the timer output is again asserted later on.
We do need to capture this state when migrating VCPUs between physical
CPUs, however, which we use the vcpu put/load functions for, which are
called through preempt notifiers whenever the thread is scheduled away
from the CPU or called directly if we return from the ioctl to
userspace.
One caveat is that we have to save and restore the timer state in both
kvm_timer_vcpu_[put/load] and kvm_timer_[schedule/unschedule], because
we can have the following flows:
1. kvm_vcpu_block
2. kvm_timer_schedule
3. schedule
4. kvm_timer_vcpu_put (preempt notifier)
5. schedule (vcpu thread gets scheduled back)
6. kvm_timer_vcpu_load (preempt notifier)
7. kvm_timer_unschedule
And a version where we don't actually call schedule:
1. kvm_vcpu_block
2. kvm_timer_schedule
7. kvm_timer_unschedule
Since kvm_timer_[schedule/unschedule] may not be followed by put/load,
but put/load also may be called independently, we call the timer
save/restore functions from both paths. Since they rely on the loaded
flag to never save/restore when unnecessary, this doesn't cause any
harm, and we ensure that all invokations of either set of functions work
as intended.
An added benefit beyond not having to read and write the timer sysregs
on every entry and exit is that we no longer have to actively write the
active state to the physical distributor, because we configured the
irq for the vtimer to only get a priority drop when handling the
interrupt in the GIC driver (we called irq_set_vcpu_affinity()), and
the interrupt stays active after firing on the host.
Reviewed-by: Marc Zyngier <marc.zyngier@arm.com>
Signed-off-by: Christoffer Dall <cdall@linaro.org>
2016-10-17 02:30:38 +08:00
|
|
|
/*
|
|
|
|
* Sync the timer hardware state before enabling interrupts as
|
|
|
|
* we don't want vtimer interrupts to race with syncing the
|
|
|
|
* timer virtual interrupt state.
|
|
|
|
*/
|
2017-10-28 01:57:51 +08:00
|
|
|
if (static_branch_unlikely(&userspace_irqchip_in_use))
|
2020-04-22 15:58:22 +08:00
|
|
|
kvm_timer_sync_user(vcpu);
|
KVM: arm/arm64: Avoid timer save/restore in vcpu entry/exit
We don't need to save and restore the hardware timer state and examine
if it generates interrupts on on every entry/exit to the guest. The
timer hardware is perfectly capable of telling us when it has expired
by signaling interrupts.
When taking a vtimer interrupt in the host, we don't want to mess with
the timer configuration, we just want to forward the physical interrupt
to the guest as a virtual interrupt. We can use the split priority drop
and deactivate feature of the GIC to do this, which leaves an EOI'ed
interrupt active on the physical distributor, making sure we don't keep
taking timer interrupts which would prevent the guest from running. We
can then forward the physical interrupt to the VM using the HW bit in
the LR of the GIC, like we do already, which lets the guest directly
deactivate both the physical and virtual timer simultaneously, allowing
the timer hardware to exit the VM and generate a new physical interrupt
when the timer output is again asserted later on.
We do need to capture this state when migrating VCPUs between physical
CPUs, however, which we use the vcpu put/load functions for, which are
called through preempt notifiers whenever the thread is scheduled away
from the CPU or called directly if we return from the ioctl to
userspace.
One caveat is that we have to save and restore the timer state in both
kvm_timer_vcpu_[put/load] and kvm_timer_[schedule/unschedule], because
we can have the following flows:
1. kvm_vcpu_block
2. kvm_timer_schedule
3. schedule
4. kvm_timer_vcpu_put (preempt notifier)
5. schedule (vcpu thread gets scheduled back)
6. kvm_timer_vcpu_load (preempt notifier)
7. kvm_timer_unschedule
And a version where we don't actually call schedule:
1. kvm_vcpu_block
2. kvm_timer_schedule
7. kvm_timer_unschedule
Since kvm_timer_[schedule/unschedule] may not be followed by put/load,
but put/load also may be called independently, we call the timer
save/restore functions from both paths. Since they rely on the loaded
flag to never save/restore when unnecessary, this doesn't cause any
harm, and we ensure that all invokations of either set of functions work
as intended.
An added benefit beyond not having to read and write the timer sysregs
on every entry and exit is that we no longer have to actively write the
active state to the physical distributor, because we configured the
irq for the vtimer to only get a priority drop when handling the
interrupt in the GIC driver (we called irq_set_vcpu_affinity()), and
the interrupt stays active after firing on the host.
Reviewed-by: Marc Zyngier <marc.zyngier@arm.com>
Signed-off-by: Christoffer Dall <cdall@linaro.org>
2016-10-17 02:30:38 +08:00
|
|
|
|
2018-04-06 21:55:59 +08:00
|
|
|
kvm_arch_vcpu_ctxsync_fp(vcpu);
|
|
|
|
|
KVM: ARM: World-switch implementation
Provides complete world-switch implementation to switch to other guests
running in non-secure modes. Includes Hyp exception handlers that
capture necessary exception information and stores the information on
the VCPU and KVM structures.
The following Hyp-ABI is also documented in the code:
Hyp-ABI: Calling HYP-mode functions from host (in SVC mode):
Switching to Hyp mode is done through a simple HVC #0 instruction. The
exception vector code will check that the HVC comes from VMID==0 and if
so will push the necessary state (SPSR, lr_usr) on the Hyp stack.
- r0 contains a pointer to a HYP function
- r1, r2, and r3 contain arguments to the above function.
- The HYP function will be called with its arguments in r0, r1 and r2.
On HYP function return, we return directly to SVC.
A call to a function executing in Hyp mode is performed like the following:
<svc code>
ldr r0, =BSYM(my_hyp_fn)
ldr r1, =my_param
hvc #0 ; Call my_hyp_fn(my_param) from HYP mode
<svc code>
Otherwise, the world-switch is pretty straight-forward. All state that
can be modified by the guest is first backed up on the Hyp stack and the
VCPU values is loaded onto the hardware. State, which is not loaded, but
theoretically modifiable by the guest is protected through the
virtualiation features to generate a trap and cause software emulation.
Upon guest returns, all state is restored from hardware onto the VCPU
struct and the original state is restored from the Hyp-stack onto the
hardware.
SMP support using the VMPIDR calculated on the basis of the host MPIDR
and overriding the low bits with KVM vcpu_id contributed by Marc Zyngier.
Reuse of VMIDs has been implemented by Antonios Motakis and adapated from
a separate patch into the appropriate patches introducing the
functionality. Note that the VMIDs are stored per VM as required by the ARM
architecture reference manual.
To support VFP/NEON we trap those instructions using the HPCTR. When
we trap, we switch the FPU. After a guest exit, the VFP state is
returned to the host. When disabling access to floating point
instructions, we also mask FPEXC_EN in order to avoid the guest
receiving Undefined instruction exceptions before we have a chance to
switch back the floating point state. We are reusing vfp_hard_struct,
so we depend on VFPv3 being enabled in the host kernel, if not, we still
trap cp10 and cp11 in order to inject an undefined instruction exception
whenever the guest tries to use VFP/NEON. VFP/NEON developed by
Antionios Motakis and Rusty Russell.
Aborts that are permission faults, and not stage-1 page table walk, do
not report the faulting address in the HPFAR. We have to resolve the
IPA, and store it just like the HPFAR register on the VCPU struct. If
the IPA cannot be resolved, it means another CPU is playing with the
page tables, and we simply restart the guest. This quirk was fixed by
Marc Zyngier.
Reviewed-by: Will Deacon <will.deacon@arm.com>
Reviewed-by: Marcelo Tosatti <mtosatti@redhat.com>
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Signed-off-by: Antonios Motakis <a.motakis@virtualopensystems.com>
Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
Signed-off-by: Christoffer Dall <c.dall@virtualopensystems.com>
2013-01-21 07:47:42 +08:00
|
|
|
/*
|
2022-02-01 21:29:23 +08:00
|
|
|
* We must ensure that any pending interrupts are taken before
|
|
|
|
* we exit guest timing so that timer ticks are accounted as
|
|
|
|
* guest time. Transiently unmask interrupts so that any
|
|
|
|
* pending interrupts are taken.
|
KVM: ARM: World-switch implementation
Provides complete world-switch implementation to switch to other guests
running in non-secure modes. Includes Hyp exception handlers that
capture necessary exception information and stores the information on
the VCPU and KVM structures.
The following Hyp-ABI is also documented in the code:
Hyp-ABI: Calling HYP-mode functions from host (in SVC mode):
Switching to Hyp mode is done through a simple HVC #0 instruction. The
exception vector code will check that the HVC comes from VMID==0 and if
so will push the necessary state (SPSR, lr_usr) on the Hyp stack.
- r0 contains a pointer to a HYP function
- r1, r2, and r3 contain arguments to the above function.
- The HYP function will be called with its arguments in r0, r1 and r2.
On HYP function return, we return directly to SVC.
A call to a function executing in Hyp mode is performed like the following:
<svc code>
ldr r0, =BSYM(my_hyp_fn)
ldr r1, =my_param
hvc #0 ; Call my_hyp_fn(my_param) from HYP mode
<svc code>
Otherwise, the world-switch is pretty straight-forward. All state that
can be modified by the guest is first backed up on the Hyp stack and the
VCPU values is loaded onto the hardware. State, which is not loaded, but
theoretically modifiable by the guest is protected through the
virtualiation features to generate a trap and cause software emulation.
Upon guest returns, all state is restored from hardware onto the VCPU
struct and the original state is restored from the Hyp-stack onto the
hardware.
SMP support using the VMPIDR calculated on the basis of the host MPIDR
and overriding the low bits with KVM vcpu_id contributed by Marc Zyngier.
Reuse of VMIDs has been implemented by Antonios Motakis and adapated from
a separate patch into the appropriate patches introducing the
functionality. Note that the VMIDs are stored per VM as required by the ARM
architecture reference manual.
To support VFP/NEON we trap those instructions using the HPCTR. When
we trap, we switch the FPU. After a guest exit, the VFP state is
returned to the host. When disabling access to floating point
instructions, we also mask FPEXC_EN in order to avoid the guest
receiving Undefined instruction exceptions before we have a chance to
switch back the floating point state. We are reusing vfp_hard_struct,
so we depend on VFPv3 being enabled in the host kernel, if not, we still
trap cp10 and cp11 in order to inject an undefined instruction exception
whenever the guest tries to use VFP/NEON. VFP/NEON developed by
Antionios Motakis and Rusty Russell.
Aborts that are permission faults, and not stage-1 page table walk, do
not report the faulting address in the HPFAR. We have to resolve the
IPA, and store it just like the HPFAR register on the VCPU struct. If
the IPA cannot be resolved, it means another CPU is playing with the
page tables, and we simply restart the guest. This quirk was fixed by
Marc Zyngier.
Reviewed-by: Will Deacon <will.deacon@arm.com>
Reviewed-by: Marcelo Tosatti <mtosatti@redhat.com>
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Signed-off-by: Antonios Motakis <a.motakis@virtualopensystems.com>
Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
Signed-off-by: Christoffer Dall <c.dall@virtualopensystems.com>
2013-01-21 07:47:42 +08:00
|
|
|
*
|
2022-02-01 21:29:23 +08:00
|
|
|
* Per ARM DDI 0487G.b section D1.13.4, an ISB (or other
|
|
|
|
* context synchronization event) is necessary to ensure that
|
|
|
|
* pending interrupts are taken.
|
KVM: ARM: World-switch implementation
Provides complete world-switch implementation to switch to other guests
running in non-secure modes. Includes Hyp exception handlers that
capture necessary exception information and stores the information on
the VCPU and KVM structures.
The following Hyp-ABI is also documented in the code:
Hyp-ABI: Calling HYP-mode functions from host (in SVC mode):
Switching to Hyp mode is done through a simple HVC #0 instruction. The
exception vector code will check that the HVC comes from VMID==0 and if
so will push the necessary state (SPSR, lr_usr) on the Hyp stack.
- r0 contains a pointer to a HYP function
- r1, r2, and r3 contain arguments to the above function.
- The HYP function will be called with its arguments in r0, r1 and r2.
On HYP function return, we return directly to SVC.
A call to a function executing in Hyp mode is performed like the following:
<svc code>
ldr r0, =BSYM(my_hyp_fn)
ldr r1, =my_param
hvc #0 ; Call my_hyp_fn(my_param) from HYP mode
<svc code>
Otherwise, the world-switch is pretty straight-forward. All state that
can be modified by the guest is first backed up on the Hyp stack and the
VCPU values is loaded onto the hardware. State, which is not loaded, but
theoretically modifiable by the guest is protected through the
virtualiation features to generate a trap and cause software emulation.
Upon guest returns, all state is restored from hardware onto the VCPU
struct and the original state is restored from the Hyp-stack onto the
hardware.
SMP support using the VMPIDR calculated on the basis of the host MPIDR
and overriding the low bits with KVM vcpu_id contributed by Marc Zyngier.
Reuse of VMIDs has been implemented by Antonios Motakis and adapated from
a separate patch into the appropriate patches introducing the
functionality. Note that the VMIDs are stored per VM as required by the ARM
architecture reference manual.
To support VFP/NEON we trap those instructions using the HPCTR. When
we trap, we switch the FPU. After a guest exit, the VFP state is
returned to the host. When disabling access to floating point
instructions, we also mask FPEXC_EN in order to avoid the guest
receiving Undefined instruction exceptions before we have a chance to
switch back the floating point state. We are reusing vfp_hard_struct,
so we depend on VFPv3 being enabled in the host kernel, if not, we still
trap cp10 and cp11 in order to inject an undefined instruction exception
whenever the guest tries to use VFP/NEON. VFP/NEON developed by
Antionios Motakis and Rusty Russell.
Aborts that are permission faults, and not stage-1 page table walk, do
not report the faulting address in the HPFAR. We have to resolve the
IPA, and store it just like the HPFAR register on the VCPU struct. If
the IPA cannot be resolved, it means another CPU is playing with the
page tables, and we simply restart the guest. This quirk was fixed by
Marc Zyngier.
Reviewed-by: Will Deacon <will.deacon@arm.com>
Reviewed-by: Marcelo Tosatti <mtosatti@redhat.com>
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Signed-off-by: Antonios Motakis <a.motakis@virtualopensystems.com>
Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
Signed-off-by: Christoffer Dall <c.dall@virtualopensystems.com>
2013-01-21 07:47:42 +08:00
|
|
|
*/
|
2022-03-04 20:04:49 +08:00
|
|
|
if (ARM_EXCEPTION_CODE(ret) == ARM_EXCEPTION_IRQ) {
|
|
|
|
local_irq_enable();
|
|
|
|
isb();
|
|
|
|
local_irq_disable();
|
|
|
|
}
|
2022-02-01 21:29:23 +08:00
|
|
|
|
|
|
|
guest_timing_exit_irqoff();
|
|
|
|
|
|
|
|
local_irq_enable();
|
KVM: ARM: World-switch implementation
Provides complete world-switch implementation to switch to other guests
running in non-secure modes. Includes Hyp exception handlers that
capture necessary exception information and stores the information on
the VCPU and KVM structures.
The following Hyp-ABI is also documented in the code:
Hyp-ABI: Calling HYP-mode functions from host (in SVC mode):
Switching to Hyp mode is done through a simple HVC #0 instruction. The
exception vector code will check that the HVC comes from VMID==0 and if
so will push the necessary state (SPSR, lr_usr) on the Hyp stack.
- r0 contains a pointer to a HYP function
- r1, r2, and r3 contain arguments to the above function.
- The HYP function will be called with its arguments in r0, r1 and r2.
On HYP function return, we return directly to SVC.
A call to a function executing in Hyp mode is performed like the following:
<svc code>
ldr r0, =BSYM(my_hyp_fn)
ldr r1, =my_param
hvc #0 ; Call my_hyp_fn(my_param) from HYP mode
<svc code>
Otherwise, the world-switch is pretty straight-forward. All state that
can be modified by the guest is first backed up on the Hyp stack and the
VCPU values is loaded onto the hardware. State, which is not loaded, but
theoretically modifiable by the guest is protected through the
virtualiation features to generate a trap and cause software emulation.
Upon guest returns, all state is restored from hardware onto the VCPU
struct and the original state is restored from the Hyp-stack onto the
hardware.
SMP support using the VMPIDR calculated on the basis of the host MPIDR
and overriding the low bits with KVM vcpu_id contributed by Marc Zyngier.
Reuse of VMIDs has been implemented by Antonios Motakis and adapated from
a separate patch into the appropriate patches introducing the
functionality. Note that the VMIDs are stored per VM as required by the ARM
architecture reference manual.
To support VFP/NEON we trap those instructions using the HPCTR. When
we trap, we switch the FPU. After a guest exit, the VFP state is
returned to the host. When disabling access to floating point
instructions, we also mask FPEXC_EN in order to avoid the guest
receiving Undefined instruction exceptions before we have a chance to
switch back the floating point state. We are reusing vfp_hard_struct,
so we depend on VFPv3 being enabled in the host kernel, if not, we still
trap cp10 and cp11 in order to inject an undefined instruction exception
whenever the guest tries to use VFP/NEON. VFP/NEON developed by
Antionios Motakis and Rusty Russell.
Aborts that are permission faults, and not stage-1 page table walk, do
not report the faulting address in the HPFAR. We have to resolve the
IPA, and store it just like the HPFAR register on the VCPU struct. If
the IPA cannot be resolved, it means another CPU is playing with the
page tables, and we simply restart the guest. This quirk was fixed by
Marc Zyngier.
Reviewed-by: Will Deacon <will.deacon@arm.com>
Reviewed-by: Marcelo Tosatti <mtosatti@redhat.com>
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Signed-off-by: Antonios Motakis <a.motakis@virtualopensystems.com>
Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
Signed-off-by: Christoffer Dall <c.dall@virtualopensystems.com>
2013-01-21 07:47:42 +08:00
|
|
|
|
2015-08-30 21:55:22 +08:00
|
|
|
trace_kvm_exit(ret, kvm_vcpu_trap_get_class(vcpu), *vcpu_pc(vcpu));
|
2015-05-29 02:49:10 +08:00
|
|
|
|
2018-01-16 03:39:04 +08:00
|
|
|
/* Exit types that need handling before we can be preempted */
|
2020-06-23 21:14:15 +08:00
|
|
|
handle_exit_early(vcpu, ret);
|
2018-01-16 03:39:04 +08:00
|
|
|
|
2015-06-08 22:00:28 +08:00
|
|
|
preempt_enable();
|
|
|
|
|
2020-10-28 05:51:13 +08:00
|
|
|
/*
|
|
|
|
* The ARMv8 architecture doesn't give the hypervisor
|
|
|
|
* a mechanism to prevent a guest from dropping to AArch32 EL0
|
|
|
|
* if implemented by the CPU. If we spot the guest in such
|
|
|
|
* state and that we decided it wasn't supposed to do so (like
|
|
|
|
* with the asymmetric AArch32 case), return to userspace with
|
|
|
|
* a fatal error.
|
|
|
|
*/
|
2021-06-09 02:02:56 +08:00
|
|
|
if (vcpu_mode_is_bad_32bit(vcpu)) {
|
2020-10-28 05:51:13 +08:00
|
|
|
/*
|
|
|
|
* As we have caught the guest red-handed, decide that
|
|
|
|
* it isn't fit for purpose anymore by making the vcpu
|
|
|
|
* invalid. The VMM can try and fix it by issuing a
|
|
|
|
* KVM_ARM_VCPU_INIT if it really wants to.
|
|
|
|
*/
|
|
|
|
vcpu->arch.target = -1;
|
|
|
|
ret = ARM_EXCEPTION_IL;
|
|
|
|
}
|
|
|
|
|
2020-06-23 21:14:15 +08:00
|
|
|
ret = handle_exit(vcpu, ret);
|
KVM: ARM: World-switch implementation
Provides complete world-switch implementation to switch to other guests
running in non-secure modes. Includes Hyp exception handlers that
capture necessary exception information and stores the information on
the VCPU and KVM structures.
The following Hyp-ABI is also documented in the code:
Hyp-ABI: Calling HYP-mode functions from host (in SVC mode):
Switching to Hyp mode is done through a simple HVC #0 instruction. The
exception vector code will check that the HVC comes from VMID==0 and if
so will push the necessary state (SPSR, lr_usr) on the Hyp stack.
- r0 contains a pointer to a HYP function
- r1, r2, and r3 contain arguments to the above function.
- The HYP function will be called with its arguments in r0, r1 and r2.
On HYP function return, we return directly to SVC.
A call to a function executing in Hyp mode is performed like the following:
<svc code>
ldr r0, =BSYM(my_hyp_fn)
ldr r1, =my_param
hvc #0 ; Call my_hyp_fn(my_param) from HYP mode
<svc code>
Otherwise, the world-switch is pretty straight-forward. All state that
can be modified by the guest is first backed up on the Hyp stack and the
VCPU values is loaded onto the hardware. State, which is not loaded, but
theoretically modifiable by the guest is protected through the
virtualiation features to generate a trap and cause software emulation.
Upon guest returns, all state is restored from hardware onto the VCPU
struct and the original state is restored from the Hyp-stack onto the
hardware.
SMP support using the VMPIDR calculated on the basis of the host MPIDR
and overriding the low bits with KVM vcpu_id contributed by Marc Zyngier.
Reuse of VMIDs has been implemented by Antonios Motakis and adapated from
a separate patch into the appropriate patches introducing the
functionality. Note that the VMIDs are stored per VM as required by the ARM
architecture reference manual.
To support VFP/NEON we trap those instructions using the HPCTR. When
we trap, we switch the FPU. After a guest exit, the VFP state is
returned to the host. When disabling access to floating point
instructions, we also mask FPEXC_EN in order to avoid the guest
receiving Undefined instruction exceptions before we have a chance to
switch back the floating point state. We are reusing vfp_hard_struct,
so we depend on VFPv3 being enabled in the host kernel, if not, we still
trap cp10 and cp11 in order to inject an undefined instruction exception
whenever the guest tries to use VFP/NEON. VFP/NEON developed by
Antionios Motakis and Rusty Russell.
Aborts that are permission faults, and not stage-1 page table walk, do
not report the faulting address in the HPFAR. We have to resolve the
IPA, and store it just like the HPFAR register on the VCPU struct. If
the IPA cannot be resolved, it means another CPU is playing with the
page tables, and we simply restart the guest. This quirk was fixed by
Marc Zyngier.
Reviewed-by: Will Deacon <will.deacon@arm.com>
Reviewed-by: Marcelo Tosatti <mtosatti@redhat.com>
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Signed-off-by: Antonios Motakis <a.motakis@virtualopensystems.com>
Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
Signed-off-by: Christoffer Dall <c.dall@virtualopensystems.com>
2013-01-21 07:47:42 +08:00
|
|
|
}
|
|
|
|
|
KVM: arm/arm64: Support arch timers with a userspace gic
If you're running with a userspace gic or other interrupt controller
(that is no vgic in the kernel), then you have so far not been able to
use the architected timers, because the output of the architected
timers, which are driven inside the kernel, was a kernel-only construct
between the arch timer code and the vgic.
This patch implements the new KVM_CAP_ARM_USER_IRQ feature, where we use a
side channel on the kvm_run structure, run->s.regs.device_irq_level, to
always notify userspace of the timer output levels when using a userspace
irqchip.
This works by ensuring that before we enter the guest, if the timer
output level has changed compared to what we last told userspace, we
don't enter the guest, but instead return to userspace to notify it of
the new level. If we are exiting, because of an MMIO for example, and
the level changed at the same time, the value is also updated and
userspace can sample the line as it needs. This is nicely achieved
simply always updating the timer_irq_level field after the main run
loop.
Note that the kvm_timer_update_irq trace event is changed to show the
host IRQ number for the timer instead of the guest IRQ number, because
the kernel no longer know which IRQ userspace wires up the timer signal
to.
Also note that this patch implements all required functionality but does
not yet advertise the capability.
Reviewed-by: Alexander Graf <agraf@suse.de>
Reviewed-by: Marc Zyngier <marc.zyngier@arm.com>
Signed-off-by: Alexander Graf <agraf@suse.de>
Signed-off-by: Christoffer Dall <christoffer.dall@linaro.org>
2016-09-28 03:08:06 +08:00
|
|
|
/* Tell userspace about in-kernel device output levels */
|
2017-02-01 19:51:52 +08:00
|
|
|
if (unlikely(!irqchip_in_kernel(vcpu->kvm))) {
|
|
|
|
kvm_timer_update_run(vcpu);
|
|
|
|
kvm_pmu_update_run(vcpu);
|
|
|
|
}
|
KVM: arm/arm64: Support arch timers with a userspace gic
If you're running with a userspace gic or other interrupt controller
(that is no vgic in the kernel), then you have so far not been able to
use the architected timers, because the output of the architected
timers, which are driven inside the kernel, was a kernel-only construct
between the arch timer code and the vgic.
This patch implements the new KVM_CAP_ARM_USER_IRQ feature, where we use a
side channel on the kvm_run structure, run->s.regs.device_irq_level, to
always notify userspace of the timer output levels when using a userspace
irqchip.
This works by ensuring that before we enter the guest, if the timer
output level has changed compared to what we last told userspace, we
don't enter the guest, but instead return to userspace to notify it of
the new level. If we are exiting, because of an MMIO for example, and
the level changed at the same time, the value is also updated and
userspace can sample the line as it needs. This is nicely achieved
simply always updating the timer_irq_level field after the main run
loop.
Note that the kvm_timer_update_irq trace event is changed to show the
host IRQ number for the timer instead of the guest IRQ number, because
the kernel no longer know which IRQ userspace wires up the timer signal
to.
Also note that this patch implements all required functionality but does
not yet advertise the capability.
Reviewed-by: Alexander Graf <agraf@suse.de>
Reviewed-by: Marc Zyngier <marc.zyngier@arm.com>
Signed-off-by: Alexander Graf <agraf@suse.de>
Signed-off-by: Christoffer Dall <christoffer.dall@linaro.org>
2016-09-28 03:08:06 +08:00
|
|
|
|
2017-11-25 05:39:01 +08:00
|
|
|
kvm_sigset_deactivate(vcpu);
|
2021-05-06 22:20:12 +08:00
|
|
|
|
2021-05-26 22:18:31 +08:00
|
|
|
out:
|
2021-05-06 22:20:12 +08:00
|
|
|
/*
|
|
|
|
* In the unlikely event that we are returning to userspace
|
|
|
|
* with pending exceptions or PC adjustment, commit these
|
|
|
|
* adjustments in order to give userspace a consistent view of
|
|
|
|
* the vcpu state. Note that this relies on __kvm_adjust_pc()
|
|
|
|
* being preempt-safe on VHE.
|
|
|
|
*/
|
2022-05-28 19:38:18 +08:00
|
|
|
if (unlikely(vcpu_get_flag(vcpu, PENDING_EXCEPTION) ||
|
|
|
|
vcpu_get_flag(vcpu, INCREMENT_PC)))
|
2021-05-06 22:20:12 +08:00
|
|
|
kvm_call_hyp(__kvm_adjust_pc, vcpu);
|
2017-11-25 05:39:01 +08:00
|
|
|
|
2017-12-05 04:35:25 +08:00
|
|
|
vcpu_put(vcpu);
|
KVM: ARM: World-switch implementation
Provides complete world-switch implementation to switch to other guests
running in non-secure modes. Includes Hyp exception handlers that
capture necessary exception information and stores the information on
the VCPU and KVM structures.
The following Hyp-ABI is also documented in the code:
Hyp-ABI: Calling HYP-mode functions from host (in SVC mode):
Switching to Hyp mode is done through a simple HVC #0 instruction. The
exception vector code will check that the HVC comes from VMID==0 and if
so will push the necessary state (SPSR, lr_usr) on the Hyp stack.
- r0 contains a pointer to a HYP function
- r1, r2, and r3 contain arguments to the above function.
- The HYP function will be called with its arguments in r0, r1 and r2.
On HYP function return, we return directly to SVC.
A call to a function executing in Hyp mode is performed like the following:
<svc code>
ldr r0, =BSYM(my_hyp_fn)
ldr r1, =my_param
hvc #0 ; Call my_hyp_fn(my_param) from HYP mode
<svc code>
Otherwise, the world-switch is pretty straight-forward. All state that
can be modified by the guest is first backed up on the Hyp stack and the
VCPU values is loaded onto the hardware. State, which is not loaded, but
theoretically modifiable by the guest is protected through the
virtualiation features to generate a trap and cause software emulation.
Upon guest returns, all state is restored from hardware onto the VCPU
struct and the original state is restored from the Hyp-stack onto the
hardware.
SMP support using the VMPIDR calculated on the basis of the host MPIDR
and overriding the low bits with KVM vcpu_id contributed by Marc Zyngier.
Reuse of VMIDs has been implemented by Antonios Motakis and adapated from
a separate patch into the appropriate patches introducing the
functionality. Note that the VMIDs are stored per VM as required by the ARM
architecture reference manual.
To support VFP/NEON we trap those instructions using the HPCTR. When
we trap, we switch the FPU. After a guest exit, the VFP state is
returned to the host. When disabling access to floating point
instructions, we also mask FPEXC_EN in order to avoid the guest
receiving Undefined instruction exceptions before we have a chance to
switch back the floating point state. We are reusing vfp_hard_struct,
so we depend on VFPv3 being enabled in the host kernel, if not, we still
trap cp10 and cp11 in order to inject an undefined instruction exception
whenever the guest tries to use VFP/NEON. VFP/NEON developed by
Antionios Motakis and Rusty Russell.
Aborts that are permission faults, and not stage-1 page table walk, do
not report the faulting address in the HPFAR. We have to resolve the
IPA, and store it just like the HPFAR register on the VCPU struct. If
the IPA cannot be resolved, it means another CPU is playing with the
page tables, and we simply restart the guest. This quirk was fixed by
Marc Zyngier.
Reviewed-by: Will Deacon <will.deacon@arm.com>
Reviewed-by: Marcelo Tosatti <mtosatti@redhat.com>
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Signed-off-by: Antonios Motakis <a.motakis@virtualopensystems.com>
Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
Signed-off-by: Christoffer Dall <c.dall@virtualopensystems.com>
2013-01-21 07:47:42 +08:00
|
|
|
return ret;
|
2013-01-21 07:28:06 +08:00
|
|
|
}
|
|
|
|
|
2013-01-21 07:28:08 +08:00
|
|
|
static int vcpu_interrupt_line(struct kvm_vcpu *vcpu, int number, bool level)
|
|
|
|
{
|
|
|
|
int bit_index;
|
|
|
|
bool set;
|
2017-08-03 18:09:05 +08:00
|
|
|
unsigned long *hcr;
|
2013-01-21 07:28:08 +08:00
|
|
|
|
|
|
|
if (number == KVM_ARM_IRQ_CPU_IRQ)
|
|
|
|
bit_index = __ffs(HCR_VI);
|
|
|
|
else /* KVM_ARM_IRQ_CPU_FIQ */
|
|
|
|
bit_index = __ffs(HCR_VF);
|
|
|
|
|
2017-08-03 18:09:05 +08:00
|
|
|
hcr = vcpu_hcr(vcpu);
|
2013-01-21 07:28:08 +08:00
|
|
|
if (level)
|
2017-08-03 18:09:05 +08:00
|
|
|
set = test_and_set_bit(bit_index, hcr);
|
2013-01-21 07:28:08 +08:00
|
|
|
else
|
2017-08-03 18:09:05 +08:00
|
|
|
set = test_and_clear_bit(bit_index, hcr);
|
2013-01-21 07:28:08 +08:00
|
|
|
|
|
|
|
/*
|
|
|
|
* If we didn't change anything, no need to wake up or kick other CPUs
|
|
|
|
*/
|
|
|
|
if (set == level)
|
|
|
|
return 0;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* The vcpu irq_lines field was updated, wake up sleeping VCPUs and
|
|
|
|
* trigger a world-switch round on the running physical CPU to set the
|
|
|
|
* virtual IRQ/FIQ fields in the HCR appropriately.
|
|
|
|
*/
|
2017-06-04 20:43:59 +08:00
|
|
|
kvm_make_request(KVM_REQ_IRQ_PENDING, vcpu);
|
2013-01-21 07:28:08 +08:00
|
|
|
kvm_vcpu_kick(vcpu);
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2013-04-17 01:21:41 +08:00
|
|
|
int kvm_vm_ioctl_irq_line(struct kvm *kvm, struct kvm_irq_level *irq_level,
|
|
|
|
bool line_status)
|
2013-01-21 07:28:08 +08:00
|
|
|
{
|
|
|
|
u32 irq = irq_level->irq;
|
|
|
|
unsigned int irq_type, vcpu_idx, irq_num;
|
|
|
|
int nrcpus = atomic_read(&kvm->online_vcpus);
|
|
|
|
struct kvm_vcpu *vcpu = NULL;
|
|
|
|
bool level = irq_level->level;
|
|
|
|
|
|
|
|
irq_type = (irq >> KVM_ARM_IRQ_TYPE_SHIFT) & KVM_ARM_IRQ_TYPE_MASK;
|
|
|
|
vcpu_idx = (irq >> KVM_ARM_IRQ_VCPU_SHIFT) & KVM_ARM_IRQ_VCPU_MASK;
|
KVM: arm/arm64: vgic: Allow more than 256 vcpus for KVM_IRQ_LINE
While parts of the VGIC support a large number of vcpus (we
bravely allow up to 512), other parts are more limited.
One of these limits is visible in the KVM_IRQ_LINE ioctl, which
only allows 256 vcpus to be signalled when using the CPU or PPI
types. Unfortunately, we've cornered ourselves badly by allocating
all the bits in the irq field.
Since the irq_type subfield (8 bit wide) is currently only taking
the values 0, 1 and 2 (and we have been careful not to allow anything
else), let's reduce this field to only 4 bits, and allocate the
remaining 4 bits to a vcpu2_index, which acts as a multiplier:
vcpu_id = 256 * vcpu2_index + vcpu_index
With that, and a new capability (KVM_CAP_ARM_IRQ_LINE_LAYOUT_2)
allowing this to be discovered, it becomes possible to inject
PPIs to up to 4096 vcpus. But please just don't.
Whilst we're there, add a clarification about the use of KVM_IRQ_LINE
on arm, which is not completely conditionned by KVM_CAP_IRQCHIP.
Reported-by: Zenghui Yu <yuzenghui@huawei.com>
Reviewed-by: Eric Auger <eric.auger@redhat.com>
Reviewed-by: Zenghui Yu <yuzenghui@huawei.com>
Signed-off-by: Marc Zyngier <maz@kernel.org>
2019-08-18 21:09:47 +08:00
|
|
|
vcpu_idx += ((irq >> KVM_ARM_IRQ_VCPU2_SHIFT) & KVM_ARM_IRQ_VCPU2_MASK) * (KVM_ARM_IRQ_VCPU_MASK + 1);
|
2013-01-21 07:28:08 +08:00
|
|
|
irq_num = (irq >> KVM_ARM_IRQ_NUM_SHIFT) & KVM_ARM_IRQ_NUM_MASK;
|
|
|
|
|
|
|
|
trace_kvm_irq_line(irq_type, vcpu_idx, irq_num, irq_level->level);
|
|
|
|
|
2013-01-22 08:36:15 +08:00
|
|
|
switch (irq_type) {
|
|
|
|
case KVM_ARM_IRQ_TYPE_CPU:
|
|
|
|
if (irqchip_in_kernel(kvm))
|
|
|
|
return -ENXIO;
|
2013-01-21 07:28:08 +08:00
|
|
|
|
2013-01-22 08:36:15 +08:00
|
|
|
if (vcpu_idx >= nrcpus)
|
|
|
|
return -EINVAL;
|
2013-01-21 07:28:08 +08:00
|
|
|
|
2013-01-22 08:36:15 +08:00
|
|
|
vcpu = kvm_get_vcpu(kvm, vcpu_idx);
|
|
|
|
if (!vcpu)
|
|
|
|
return -EINVAL;
|
2013-01-21 07:28:08 +08:00
|
|
|
|
2013-01-22 08:36:15 +08:00
|
|
|
if (irq_num > KVM_ARM_IRQ_CPU_FIQ)
|
|
|
|
return -EINVAL;
|
|
|
|
|
|
|
|
return vcpu_interrupt_line(vcpu, irq_num, level);
|
|
|
|
case KVM_ARM_IRQ_TYPE_PPI:
|
|
|
|
if (!irqchip_in_kernel(kvm))
|
|
|
|
return -ENXIO;
|
|
|
|
|
|
|
|
if (vcpu_idx >= nrcpus)
|
|
|
|
return -EINVAL;
|
|
|
|
|
|
|
|
vcpu = kvm_get_vcpu(kvm, vcpu_idx);
|
|
|
|
if (!vcpu)
|
|
|
|
return -EINVAL;
|
|
|
|
|
|
|
|
if (irq_num < VGIC_NR_SGIS || irq_num >= VGIC_NR_PRIVATE_IRQS)
|
|
|
|
return -EINVAL;
|
2013-01-21 07:28:08 +08:00
|
|
|
|
2017-05-16 18:41:18 +08:00
|
|
|
return kvm_vgic_inject_irq(kvm, vcpu->vcpu_id, irq_num, level, NULL);
|
2013-01-22 08:36:15 +08:00
|
|
|
case KVM_ARM_IRQ_TYPE_SPI:
|
|
|
|
if (!irqchip_in_kernel(kvm))
|
|
|
|
return -ENXIO;
|
|
|
|
|
KVM: arm/arm64: check IRQ number on userland injection
When userland injects a SPI via the KVM_IRQ_LINE ioctl we currently
only check it against a fixed limit, which historically is set
to 127. With the new dynamic IRQ allocation the effective limit may
actually be smaller (64).
So when now a malicious or buggy userland injects a SPI in that
range, we spill over on our VGIC bitmaps and bytemaps memory.
I could trigger a host kernel NULL pointer dereference with current
mainline by injecting some bogus IRQ number from a hacked kvmtool:
-----------------
....
DEBUG: kvm_vgic_inject_irq(kvm, cpu=0, irq=114, level=1)
DEBUG: vgic_update_irq_pending(kvm, cpu=0, irq=114, level=1)
DEBUG: IRQ #114 still in the game, writing to bytemap now...
Unable to handle kernel NULL pointer dereference at virtual address 00000000
pgd = ffffffc07652e000
[00000000] *pgd=00000000f658b003, *pud=00000000f658b003, *pmd=0000000000000000
Internal error: Oops: 96000006 [#1] PREEMPT SMP
Modules linked in:
CPU: 1 PID: 1053 Comm: lkvm-msi-irqinj Not tainted 4.0.0-rc7+ #3027
Hardware name: FVP Base (DT)
task: ffffffc0774e9680 ti: ffffffc0765a8000 task.ti: ffffffc0765a8000
PC is at kvm_vgic_inject_irq+0x234/0x310
LR is at kvm_vgic_inject_irq+0x30c/0x310
pc : [<ffffffc0000ae0a8>] lr : [<ffffffc0000ae180>] pstate: 80000145
.....
So this patch fixes this by checking the SPI number against the
actual limit. Also we remove the former legacy hard limit of
127 in the ioctl code.
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
Reviewed-by: Christoffer Dall <christoffer.dall@linaro.org>
CC: <stable@vger.kernel.org> # 4.0, 3.19, 3.18
[maz: wrap KVM_ARM_IRQ_GIC_MAX with #ifndef __KERNEL__,
as suggested by Christopher Covington]
Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
2015-04-10 23:17:59 +08:00
|
|
|
if (irq_num < VGIC_NR_PRIVATE_IRQS)
|
2013-01-22 08:36:15 +08:00
|
|
|
return -EINVAL;
|
|
|
|
|
2017-05-16 18:41:18 +08:00
|
|
|
return kvm_vgic_inject_irq(kvm, 0, irq_num, level, NULL);
|
2013-01-22 08:36:15 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
return -EINVAL;
|
2013-01-21 07:28:08 +08:00
|
|
|
}
|
|
|
|
|
2014-10-16 22:40:53 +08:00
|
|
|
static int kvm_vcpu_set_target(struct kvm_vcpu *vcpu,
|
|
|
|
const struct kvm_vcpu_init *init)
|
|
|
|
{
|
2019-04-05 01:42:30 +08:00
|
|
|
unsigned int i, ret;
|
2021-08-12 13:09:53 +08:00
|
|
|
u32 phys_target = kvm_target_cpu();
|
2014-10-16 22:40:53 +08:00
|
|
|
|
|
|
|
if (init->target != phys_target)
|
|
|
|
return -EINVAL;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Secondary and subsequent calls to KVM_ARM_VCPU_INIT must
|
|
|
|
* use the same target.
|
|
|
|
*/
|
|
|
|
if (vcpu->arch.target != -1 && vcpu->arch.target != init->target)
|
|
|
|
return -EINVAL;
|
|
|
|
|
|
|
|
/* -ENOENT for unknown features, -EINVAL for invalid combinations. */
|
|
|
|
for (i = 0; i < sizeof(init->features) * 8; i++) {
|
|
|
|
bool set = (init->features[i / 32] & (1 << (i % 32)));
|
|
|
|
|
|
|
|
if (set && i >= KVM_VCPU_MAX_FEATURES)
|
|
|
|
return -ENOENT;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Secondary and subsequent calls to KVM_ARM_VCPU_INIT must
|
|
|
|
* use the same feature set.
|
|
|
|
*/
|
|
|
|
if (vcpu->arch.target != -1 && i < KVM_VCPU_MAX_FEATURES &&
|
|
|
|
test_bit(i, vcpu->arch.features) != set)
|
|
|
|
return -EINVAL;
|
|
|
|
|
|
|
|
if (set)
|
|
|
|
set_bit(i, vcpu->arch.features);
|
|
|
|
}
|
|
|
|
|
|
|
|
vcpu->arch.target = phys_target;
|
|
|
|
|
|
|
|
/* Now we know what it is, we can reset it. */
|
2019-04-05 01:42:30 +08:00
|
|
|
ret = kvm_reset_vcpu(vcpu);
|
|
|
|
if (ret) {
|
|
|
|
vcpu->arch.target = -1;
|
|
|
|
bitmap_zero(vcpu->arch.features, KVM_VCPU_MAX_FEATURES);
|
|
|
|
}
|
2014-10-16 22:40:53 +08:00
|
|
|
|
2019-04-05 01:42:30 +08:00
|
|
|
return ret;
|
|
|
|
}
|
2014-10-16 22:40:53 +08:00
|
|
|
|
2013-11-20 09:43:19 +08:00
|
|
|
static int kvm_arch_vcpu_ioctl_vcpu_init(struct kvm_vcpu *vcpu,
|
|
|
|
struct kvm_vcpu_init *init)
|
|
|
|
{
|
|
|
|
int ret;
|
|
|
|
|
|
|
|
ret = kvm_vcpu_set_target(vcpu, init);
|
|
|
|
if (ret)
|
|
|
|
return ret;
|
|
|
|
|
2014-11-27 17:35:03 +08:00
|
|
|
/*
|
|
|
|
* Ensure a rebooted VM will fault in RAM pages and detect if the
|
|
|
|
* guest MMU is turned off and flush the caches as needed.
|
2020-04-15 15:28:35 +08:00
|
|
|
*
|
2020-05-31 00:22:19 +08:00
|
|
|
* S2FWB enforces all memory accesses to RAM being cacheable,
|
|
|
|
* ensuring that the data side is always coherent. We still
|
|
|
|
* need to invalidate the I-cache though, as FWB does *not*
|
|
|
|
* imply CTR_EL0.DIC.
|
2014-11-27 17:35:03 +08:00
|
|
|
*/
|
2021-10-14 19:13:06 +08:00
|
|
|
if (vcpu_has_run_once(vcpu)) {
|
2020-05-31 00:22:19 +08:00
|
|
|
if (!cpus_have_final_cap(ARM64_HAS_STAGE2_FWB))
|
|
|
|
stage2_unmap_vm(vcpu->kvm);
|
|
|
|
else
|
arm64: Rename arm64-internal cache maintenance functions
Although naming across the codebase isn't that consistent, it
tends to follow certain patterns. Moreover, the term "flush"
isn't defined in the Arm Architecture reference manual, and might
be interpreted to mean clean, invalidate, or both for a cache.
Rename arm64-internal functions to make the naming internally
consistent, as well as making it consistent with the Arm ARM, by
specifying whether it applies to the instruction, data, or both
caches, whether the operation is a clean, invalidate, or both.
Also specify which point the operation applies to, i.e., to the
point of unification (PoU), coherency (PoC), or persistence
(PoP).
This commit applies the following sed transformation to all files
under arch/arm64:
"s/\b__flush_cache_range\b/caches_clean_inval_pou_macro/g;"\
"s/\b__flush_icache_range\b/caches_clean_inval_pou/g;"\
"s/\binvalidate_icache_range\b/icache_inval_pou/g;"\
"s/\b__flush_dcache_area\b/dcache_clean_inval_poc/g;"\
"s/\b__inval_dcache_area\b/dcache_inval_poc/g;"\
"s/__clean_dcache_area_poc\b/dcache_clean_poc/g;"\
"s/\b__clean_dcache_area_pop\b/dcache_clean_pop/g;"\
"s/\b__clean_dcache_area_pou\b/dcache_clean_pou/g;"\
"s/\b__flush_cache_user_range\b/caches_clean_inval_user_pou/g;"\
"s/\b__flush_icache_all\b/icache_inval_all_pou/g;"
Note that __clean_dcache_area_poc is deliberately missing a word
boundary check at the beginning in order to match the efistub
symbols in image-vars.h.
Also note that, despite its name, __flush_icache_range operates
on both instruction and data caches. The name change here
reflects that.
No functional change intended.
Acked-by: Mark Rutland <mark.rutland@arm.com>
Signed-off-by: Fuad Tabba <tabba@google.com>
Reviewed-by: Ard Biesheuvel <ardb@kernel.org>
Link: https://lore.kernel.org/r/20210524083001.2586635-19-tabba@google.com
Signed-off-by: Will Deacon <will@kernel.org>
2021-05-24 16:30:01 +08:00
|
|
|
icache_inval_all_pou();
|
2020-05-31 00:22:19 +08:00
|
|
|
}
|
2014-11-27 17:35:03 +08:00
|
|
|
|
2014-10-16 23:21:16 +08:00
|
|
|
vcpu_reset_hcr(vcpu);
|
2021-08-17 16:11:27 +08:00
|
|
|
vcpu->arch.cptr_el2 = CPTR_EL2_DEFAULT;
|
2014-10-16 23:21:16 +08:00
|
|
|
|
2013-11-20 09:43:19 +08:00
|
|
|
/*
|
2015-09-26 05:41:14 +08:00
|
|
|
* Handle the "start in power-off" case.
|
2013-11-20 09:43:19 +08:00
|
|
|
*/
|
2014-12-02 22:27:51 +08:00
|
|
|
if (test_bit(KVM_ARM_VCPU_POWER_OFF, vcpu->arch.features))
|
2022-05-04 11:24:36 +08:00
|
|
|
kvm_arm_vcpu_power_off(vcpu);
|
2014-10-16 22:14:43 +08:00
|
|
|
else
|
2022-05-04 11:24:37 +08:00
|
|
|
vcpu->arch.mp_state.mp_state = KVM_MP_STATE_RUNNABLE;
|
2013-11-20 09:43:19 +08:00
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2016-01-11 20:56:17 +08:00
|
|
|
static int kvm_arm_vcpu_set_attr(struct kvm_vcpu *vcpu,
|
|
|
|
struct kvm_device_attr *attr)
|
|
|
|
{
|
|
|
|
int ret = -ENXIO;
|
|
|
|
|
|
|
|
switch (attr->group) {
|
|
|
|
default:
|
2016-01-11 21:35:32 +08:00
|
|
|
ret = kvm_arm_vcpu_arch_set_attr(vcpu, attr);
|
2016-01-11 20:56:17 +08:00
|
|
|
break;
|
|
|
|
}
|
|
|
|
|
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
|
|
|
|
static int kvm_arm_vcpu_get_attr(struct kvm_vcpu *vcpu,
|
|
|
|
struct kvm_device_attr *attr)
|
|
|
|
{
|
|
|
|
int ret = -ENXIO;
|
|
|
|
|
|
|
|
switch (attr->group) {
|
|
|
|
default:
|
2016-01-11 21:35:32 +08:00
|
|
|
ret = kvm_arm_vcpu_arch_get_attr(vcpu, attr);
|
2016-01-11 20:56:17 +08:00
|
|
|
break;
|
|
|
|
}
|
|
|
|
|
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
|
|
|
|
static int kvm_arm_vcpu_has_attr(struct kvm_vcpu *vcpu,
|
|
|
|
struct kvm_device_attr *attr)
|
|
|
|
{
|
|
|
|
int ret = -ENXIO;
|
|
|
|
|
|
|
|
switch (attr->group) {
|
|
|
|
default:
|
2016-01-11 21:35:32 +08:00
|
|
|
ret = kvm_arm_vcpu_arch_has_attr(vcpu, attr);
|
2016-01-11 20:56:17 +08:00
|
|
|
break;
|
|
|
|
}
|
|
|
|
|
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
|
2018-07-19 23:24:24 +08:00
|
|
|
static int kvm_arm_vcpu_get_events(struct kvm_vcpu *vcpu,
|
|
|
|
struct kvm_vcpu_events *events)
|
|
|
|
{
|
|
|
|
memset(events, 0, sizeof(*events));
|
|
|
|
|
|
|
|
return __kvm_arm_vcpu_get_events(vcpu, events);
|
|
|
|
}
|
|
|
|
|
|
|
|
static int kvm_arm_vcpu_set_events(struct kvm_vcpu *vcpu,
|
|
|
|
struct kvm_vcpu_events *events)
|
|
|
|
{
|
|
|
|
int i;
|
|
|
|
|
|
|
|
/* check whether the reserved field is zero */
|
|
|
|
for (i = 0; i < ARRAY_SIZE(events->reserved); i++)
|
|
|
|
if (events->reserved[i])
|
|
|
|
return -EINVAL;
|
|
|
|
|
|
|
|
/* check whether the pad field is zero */
|
|
|
|
for (i = 0; i < ARRAY_SIZE(events->exception.pad); i++)
|
|
|
|
if (events->exception.pad[i])
|
|
|
|
return -EINVAL;
|
|
|
|
|
|
|
|
return __kvm_arm_vcpu_set_events(vcpu, events);
|
|
|
|
}
|
|
|
|
|
2013-01-21 07:28:06 +08:00
|
|
|
long kvm_arch_vcpu_ioctl(struct file *filp,
|
|
|
|
unsigned int ioctl, unsigned long arg)
|
|
|
|
{
|
|
|
|
struct kvm_vcpu *vcpu = filp->private_data;
|
|
|
|
void __user *argp = (void __user *)arg;
|
2016-01-11 20:56:17 +08:00
|
|
|
struct kvm_device_attr attr;
|
2017-12-05 04:35:36 +08:00
|
|
|
long r;
|
|
|
|
|
2013-01-21 07:28:06 +08:00
|
|
|
switch (ioctl) {
|
|
|
|
case KVM_ARM_VCPU_INIT: {
|
|
|
|
struct kvm_vcpu_init init;
|
|
|
|
|
2017-12-05 04:35:36 +08:00
|
|
|
r = -EFAULT;
|
2013-01-21 07:28:06 +08:00
|
|
|
if (copy_from_user(&init, argp, sizeof(init)))
|
2017-12-05 04:35:36 +08:00
|
|
|
break;
|
2013-01-21 07:28:06 +08:00
|
|
|
|
2017-12-05 04:35:36 +08:00
|
|
|
r = kvm_arch_vcpu_ioctl_vcpu_init(vcpu, &init);
|
|
|
|
break;
|
2013-01-21 07:28:06 +08:00
|
|
|
}
|
|
|
|
case KVM_SET_ONE_REG:
|
|
|
|
case KVM_GET_ONE_REG: {
|
|
|
|
struct kvm_one_reg reg;
|
2013-05-09 06:28:06 +08:00
|
|
|
|
2017-12-05 04:35:36 +08:00
|
|
|
r = -ENOEXEC;
|
2013-05-09 06:28:06 +08:00
|
|
|
if (unlikely(!kvm_vcpu_initialized(vcpu)))
|
2017-12-05 04:35:36 +08:00
|
|
|
break;
|
2013-05-09 06:28:06 +08:00
|
|
|
|
2017-12-05 04:35:36 +08:00
|
|
|
r = -EFAULT;
|
2013-01-21 07:28:06 +08:00
|
|
|
if (copy_from_user(®, argp, sizeof(reg)))
|
2017-12-05 04:35:36 +08:00
|
|
|
break;
|
|
|
|
|
2021-08-19 04:21:31 +08:00
|
|
|
/*
|
|
|
|
* We could owe a reset due to PSCI. Handle the pending reset
|
|
|
|
* here to ensure userspace register accesses are ordered after
|
|
|
|
* the reset.
|
|
|
|
*/
|
|
|
|
if (kvm_check_request(KVM_REQ_VCPU_RESET, vcpu))
|
|
|
|
kvm_reset_vcpu(vcpu);
|
|
|
|
|
2013-01-21 07:28:06 +08:00
|
|
|
if (ioctl == KVM_SET_ONE_REG)
|
2017-12-05 04:35:36 +08:00
|
|
|
r = kvm_arm_set_reg(vcpu, ®);
|
2013-01-21 07:28:06 +08:00
|
|
|
else
|
2017-12-05 04:35:36 +08:00
|
|
|
r = kvm_arm_get_reg(vcpu, ®);
|
|
|
|
break;
|
2013-01-21 07:28:06 +08:00
|
|
|
}
|
|
|
|
case KVM_GET_REG_LIST: {
|
|
|
|
struct kvm_reg_list __user *user_list = argp;
|
|
|
|
struct kvm_reg_list reg_list;
|
|
|
|
unsigned n;
|
|
|
|
|
2017-12-05 04:35:36 +08:00
|
|
|
r = -ENOEXEC;
|
2013-05-09 06:28:06 +08:00
|
|
|
if (unlikely(!kvm_vcpu_initialized(vcpu)))
|
2017-12-05 04:35:36 +08:00
|
|
|
break;
|
2013-05-09 06:28:06 +08:00
|
|
|
|
2018-12-19 22:27:01 +08:00
|
|
|
r = -EPERM;
|
|
|
|
if (!kvm_arm_vcpu_is_finalized(vcpu))
|
|
|
|
break;
|
|
|
|
|
2017-12-05 04:35:36 +08:00
|
|
|
r = -EFAULT;
|
2013-01-21 07:28:06 +08:00
|
|
|
if (copy_from_user(®_list, user_list, sizeof(reg_list)))
|
2017-12-05 04:35:36 +08:00
|
|
|
break;
|
2013-01-21 07:28:06 +08:00
|
|
|
n = reg_list.n;
|
|
|
|
reg_list.n = kvm_arm_num_regs(vcpu);
|
|
|
|
if (copy_to_user(user_list, ®_list, sizeof(reg_list)))
|
2017-12-05 04:35:36 +08:00
|
|
|
break;
|
|
|
|
r = -E2BIG;
|
2013-01-21 07:28:06 +08:00
|
|
|
if (n < reg_list.n)
|
2017-12-05 04:35:36 +08:00
|
|
|
break;
|
|
|
|
r = kvm_arm_copy_reg_indices(vcpu, user_list->reg);
|
|
|
|
break;
|
2013-01-21 07:28:06 +08:00
|
|
|
}
|
2016-01-11 20:56:17 +08:00
|
|
|
case KVM_SET_DEVICE_ATTR: {
|
2017-12-05 04:35:36 +08:00
|
|
|
r = -EFAULT;
|
2016-01-11 20:56:17 +08:00
|
|
|
if (copy_from_user(&attr, argp, sizeof(attr)))
|
2017-12-05 04:35:36 +08:00
|
|
|
break;
|
|
|
|
r = kvm_arm_vcpu_set_attr(vcpu, &attr);
|
|
|
|
break;
|
2016-01-11 20:56:17 +08:00
|
|
|
}
|
|
|
|
case KVM_GET_DEVICE_ATTR: {
|
2017-12-05 04:35:36 +08:00
|
|
|
r = -EFAULT;
|
2016-01-11 20:56:17 +08:00
|
|
|
if (copy_from_user(&attr, argp, sizeof(attr)))
|
2017-12-05 04:35:36 +08:00
|
|
|
break;
|
|
|
|
r = kvm_arm_vcpu_get_attr(vcpu, &attr);
|
|
|
|
break;
|
2016-01-11 20:56:17 +08:00
|
|
|
}
|
|
|
|
case KVM_HAS_DEVICE_ATTR: {
|
2017-12-05 04:35:36 +08:00
|
|
|
r = -EFAULT;
|
2016-01-11 20:56:17 +08:00
|
|
|
if (copy_from_user(&attr, argp, sizeof(attr)))
|
2017-12-05 04:35:36 +08:00
|
|
|
break;
|
|
|
|
r = kvm_arm_vcpu_has_attr(vcpu, &attr);
|
|
|
|
break;
|
2016-01-11 20:56:17 +08:00
|
|
|
}
|
2018-07-19 23:24:22 +08:00
|
|
|
case KVM_GET_VCPU_EVENTS: {
|
|
|
|
struct kvm_vcpu_events events;
|
|
|
|
|
|
|
|
if (kvm_arm_vcpu_get_events(vcpu, &events))
|
|
|
|
return -EINVAL;
|
|
|
|
|
|
|
|
if (copy_to_user(argp, &events, sizeof(events)))
|
|
|
|
return -EFAULT;
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
case KVM_SET_VCPU_EVENTS: {
|
|
|
|
struct kvm_vcpu_events events;
|
|
|
|
|
|
|
|
if (copy_from_user(&events, argp, sizeof(events)))
|
|
|
|
return -EFAULT;
|
|
|
|
|
|
|
|
return kvm_arm_vcpu_set_events(vcpu, &events);
|
|
|
|
}
|
2018-12-19 22:27:01 +08:00
|
|
|
case KVM_ARM_VCPU_FINALIZE: {
|
|
|
|
int what;
|
|
|
|
|
|
|
|
if (!kvm_vcpu_initialized(vcpu))
|
|
|
|
return -ENOEXEC;
|
|
|
|
|
|
|
|
if (get_user(what, (const int __user *)argp))
|
|
|
|
return -EFAULT;
|
|
|
|
|
|
|
|
return kvm_arm_vcpu_finalize(vcpu, what);
|
|
|
|
}
|
2013-01-21 07:28:06 +08:00
|
|
|
default:
|
2017-12-05 04:35:36 +08:00
|
|
|
r = -EINVAL;
|
2013-01-21 07:28:06 +08:00
|
|
|
}
|
2017-12-05 04:35:36 +08:00
|
|
|
|
|
|
|
return r;
|
2013-01-21 07:28:06 +08:00
|
|
|
}
|
|
|
|
|
2020-02-19 05:07:29 +08:00
|
|
|
void kvm_arch_sync_dirty_log(struct kvm *kvm, struct kvm_memory_slot *memslot)
|
2013-01-21 07:28:06 +08:00
|
|
|
{
|
2015-01-16 07:58:57 +08:00
|
|
|
|
2013-01-21 07:28:06 +08:00
|
|
|
}
|
|
|
|
|
2020-02-19 05:07:29 +08:00
|
|
|
void kvm_arch_flush_remote_tlbs_memslot(struct kvm *kvm,
|
2021-04-02 23:53:09 +08:00
|
|
|
const struct kvm_memory_slot *memslot)
|
kvm: introduce manual dirty log reprotect
There are two problems with KVM_GET_DIRTY_LOG. First, and less important,
it can take kvm->mmu_lock for an extended period of time. Second, its user
can actually see many false positives in some cases. The latter is due
to a benign race like this:
1. KVM_GET_DIRTY_LOG returns a set of dirty pages and write protects
them.
2. The guest modifies the pages, causing them to be marked ditry.
3. Userspace actually copies the pages.
4. KVM_GET_DIRTY_LOG returns those pages as dirty again, even though
they were not written to since (3).
This is especially a problem for large guests, where the time between
(1) and (3) can be substantial. This patch introduces a new
capability which, when enabled, makes KVM_GET_DIRTY_LOG not
write-protect the pages it returns. Instead, userspace has to
explicitly clear the dirty log bits just before using the content
of the page. The new KVM_CLEAR_DIRTY_LOG ioctl can also operate on a
64-page granularity rather than requiring to sync a full memslot;
this way, the mmu_lock is taken for small amounts of time, and
only a small amount of time will pass between write protection
of pages and the sending of their content.
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2018-10-23 08:36:47 +08:00
|
|
|
{
|
2020-02-19 05:07:29 +08:00
|
|
|
kvm_flush_remote_tlbs(kvm);
|
2013-01-21 07:28:06 +08:00
|
|
|
}
|
|
|
|
|
2013-01-24 02:18:04 +08:00
|
|
|
static int kvm_vm_ioctl_set_device_addr(struct kvm *kvm,
|
|
|
|
struct kvm_arm_device_addr *dev_addr)
|
|
|
|
{
|
2013-01-22 08:36:13 +08:00
|
|
|
unsigned long dev_id, type;
|
|
|
|
|
|
|
|
dev_id = (dev_addr->id & KVM_ARM_DEVICE_ID_MASK) >>
|
|
|
|
KVM_ARM_DEVICE_ID_SHIFT;
|
|
|
|
type = (dev_addr->id & KVM_ARM_DEVICE_TYPE_MASK) >>
|
|
|
|
KVM_ARM_DEVICE_TYPE_SHIFT;
|
|
|
|
|
|
|
|
switch (dev_id) {
|
|
|
|
case KVM_ARM_DEVICE_VGIC_V2:
|
2015-12-18 19:38:43 +08:00
|
|
|
if (!vgic_present)
|
|
|
|
return -ENXIO;
|
2013-09-24 05:55:56 +08:00
|
|
|
return kvm_vgic_addr(kvm, type, &dev_addr->addr, true);
|
2013-01-22 08:36:13 +08:00
|
|
|
default:
|
|
|
|
return -ENODEV;
|
|
|
|
}
|
2013-01-24 02:18:04 +08:00
|
|
|
}
|
|
|
|
|
2013-01-21 07:28:06 +08:00
|
|
|
long kvm_arch_vm_ioctl(struct file *filp,
|
|
|
|
unsigned int ioctl, unsigned long arg)
|
|
|
|
{
|
2013-01-24 02:18:04 +08:00
|
|
|
struct kvm *kvm = filp->private_data;
|
|
|
|
void __user *argp = (void __user *)arg;
|
|
|
|
|
|
|
|
switch (ioctl) {
|
2013-01-22 08:36:15 +08:00
|
|
|
case KVM_CREATE_IRQCHIP: {
|
2016-08-10 01:13:01 +08:00
|
|
|
int ret;
|
2015-12-18 19:38:43 +08:00
|
|
|
if (!vgic_present)
|
|
|
|
return -ENXIO;
|
2016-08-10 01:13:01 +08:00
|
|
|
mutex_lock(&kvm->lock);
|
|
|
|
ret = kvm_vgic_create(kvm, KVM_DEV_TYPE_ARM_VGIC_V2);
|
|
|
|
mutex_unlock(&kvm->lock);
|
|
|
|
return ret;
|
2013-01-22 08:36:15 +08:00
|
|
|
}
|
2013-01-24 02:18:04 +08:00
|
|
|
case KVM_ARM_SET_DEVICE_ADDR: {
|
|
|
|
struct kvm_arm_device_addr dev_addr;
|
|
|
|
|
|
|
|
if (copy_from_user(&dev_addr, argp, sizeof(dev_addr)))
|
|
|
|
return -EFAULT;
|
|
|
|
return kvm_vm_ioctl_set_device_addr(kvm, &dev_addr);
|
|
|
|
}
|
2013-09-30 16:50:07 +08:00
|
|
|
case KVM_ARM_PREFERRED_TARGET: {
|
|
|
|
struct kvm_vcpu_init init;
|
|
|
|
|
2021-11-05 09:15:00 +08:00
|
|
|
kvm_vcpu_preferred_target(&init);
|
2013-09-30 16:50:07 +08:00
|
|
|
|
|
|
|
if (copy_to_user(argp, &init, sizeof(init)))
|
|
|
|
return -EFAULT;
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
2021-06-21 19:17:15 +08:00
|
|
|
case KVM_ARM_MTE_COPY_TAGS: {
|
|
|
|
struct kvm_arm_copy_mte_tags copy_tags;
|
|
|
|
|
|
|
|
if (copy_from_user(©_tags, argp, sizeof(copy_tags)))
|
|
|
|
return -EFAULT;
|
|
|
|
return kvm_vm_ioctl_mte_copy_tags(kvm, ©_tags);
|
|
|
|
}
|
2013-01-24 02:18:04 +08:00
|
|
|
default:
|
|
|
|
return -EINVAL;
|
|
|
|
}
|
2013-01-21 07:28:06 +08:00
|
|
|
}
|
|
|
|
|
2020-09-23 04:49:09 +08:00
|
|
|
static unsigned long nvhe_percpu_size(void)
|
|
|
|
{
|
|
|
|
return (unsigned long)CHOOSE_NVHE_SYM(__per_cpu_end) -
|
|
|
|
(unsigned long)CHOOSE_NVHE_SYM(__per_cpu_start);
|
|
|
|
}
|
|
|
|
|
|
|
|
static unsigned long nvhe_percpu_order(void)
|
|
|
|
{
|
|
|
|
unsigned long size = nvhe_percpu_size();
|
|
|
|
|
|
|
|
return size ? get_order(size) : 0;
|
|
|
|
}
|
|
|
|
|
2020-11-13 19:38:44 +08:00
|
|
|
/* A lookup table holding the hypervisor VA for each vector slot */
|
|
|
|
static void *hyp_spectre_vector_selector[BP_HARDEN_EL2_SLOTS];
|
|
|
|
|
|
|
|
static void kvm_init_vector_slot(void *base, enum arm64_hyp_spectre_vector slot)
|
2020-09-28 18:45:24 +08:00
|
|
|
{
|
2021-03-19 18:01:23 +08:00
|
|
|
hyp_spectre_vector_selector[slot] = __kvm_vector_slot2addr(base, slot);
|
2020-11-13 19:38:44 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
static int kvm_init_vector_slots(void)
|
|
|
|
{
|
|
|
|
int err;
|
|
|
|
void *base;
|
|
|
|
|
|
|
|
base = kern_hyp_va(kvm_ksym_ref(__kvm_hyp_vector));
|
|
|
|
kvm_init_vector_slot(base, HYP_VECTOR_DIRECT);
|
|
|
|
|
|
|
|
base = kern_hyp_va(kvm_ksym_ref(__bp_harden_hyp_vecs));
|
|
|
|
kvm_init_vector_slot(base, HYP_VECTOR_SPECTRE_DIRECT);
|
2020-11-13 19:38:39 +08:00
|
|
|
|
2022-05-13 17:26:07 +08:00
|
|
|
if (kvm_system_needs_idmapped_vectors() &&
|
|
|
|
!is_protected_kvm_enabled()) {
|
2020-11-13 19:38:44 +08:00
|
|
|
err = create_hyp_exec_mappings(__pa_symbol(__bp_harden_hyp_vecs),
|
|
|
|
__BP_HARDEN_HYP_VECS_SZ, &base);
|
|
|
|
if (err)
|
|
|
|
return err;
|
2020-09-28 18:45:24 +08:00
|
|
|
}
|
|
|
|
|
2020-11-13 19:38:44 +08:00
|
|
|
kvm_init_vector_slot(base, HYP_VECTOR_INDIRECT);
|
|
|
|
kvm_init_vector_slot(base, HYP_VECTOR_SPECTRE_INDIRECT);
|
2020-09-28 18:45:24 +08:00
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2021-03-19 18:01:12 +08:00
|
|
|
static void cpu_prepare_hyp_mode(int cpu)
|
2013-01-21 07:28:06 +08:00
|
|
|
{
|
2021-03-19 18:01:12 +08:00
|
|
|
struct kvm_nvhe_init_params *params = per_cpu_ptr_nvhe_sym(kvm_init_params, cpu);
|
2020-12-03 02:41:07 +08:00
|
|
|
unsigned long tcr;
|
2013-01-21 07:28:06 +08:00
|
|
|
|
2020-05-15 23:20:56 +08:00
|
|
|
/*
|
|
|
|
* Calculate the raw per-cpu offset without a translation from the
|
|
|
|
* kernel's mapping to the linear mapping, and store it in tpidr_el2
|
|
|
|
* so that we can use adr_l to access per-cpu variables in EL2.
|
2021-01-09 00:12:54 +08:00
|
|
|
* Also drop the KASAN tag which gets in the way...
|
2020-05-15 23:20:56 +08:00
|
|
|
*/
|
2021-03-19 18:01:12 +08:00
|
|
|
params->tpidr_el2 = (unsigned long)kasan_reset_tag(per_cpu_ptr_nvhe_sym(__per_cpu_start, cpu)) -
|
2020-12-03 02:41:06 +08:00
|
|
|
(unsigned long)kvm_ksym_ref(CHOOSE_NVHE_SYM(__per_cpu_start));
|
2020-05-15 23:20:56 +08:00
|
|
|
|
2020-12-03 02:41:07 +08:00
|
|
|
params->mair_el2 = read_sysreg(mair_el1);
|
|
|
|
|
|
|
|
/*
|
|
|
|
* The ID map may be configured to use an extended virtual address
|
|
|
|
* range. This is only the case if system RAM is out of range for the
|
|
|
|
* currently configured page size and VA_BITS, in which case we will
|
|
|
|
* also need the extended virtual range for the HYP ID map, or we won't
|
|
|
|
* be able to enable the EL2 MMU.
|
|
|
|
*
|
|
|
|
* However, at EL2, there is only one TTBR register, and we can't switch
|
|
|
|
* between translation tables *and* update TCR_EL2.T0SZ at the same
|
|
|
|
* time. Bottom line: we need to use the extended range with *both* our
|
|
|
|
* translation tables.
|
|
|
|
*
|
|
|
|
* So use the same T0SZ value we use for the ID map.
|
|
|
|
*/
|
|
|
|
tcr = (read_sysreg(tcr_el1) & TCR_EL2_MASK) | TCR_EL2_RES1;
|
|
|
|
tcr &= ~TCR_T0SZ_MASK;
|
|
|
|
tcr |= (idmap_t0sz & GENMASK(TCR_TxSZ_WIDTH - 1, 0)) << TCR_T0SZ_OFFSET;
|
|
|
|
params->tcr_el2 = tcr;
|
|
|
|
|
2020-12-03 02:41:06 +08:00
|
|
|
params->pgd_pa = kvm_mmu_get_httbr();
|
2021-03-19 18:01:29 +08:00
|
|
|
if (is_protected_kvm_enabled())
|
|
|
|
params->hcr_el2 = HCR_HOST_NVHE_PROTECTED_FLAGS;
|
|
|
|
else
|
|
|
|
params->hcr_el2 = HCR_HOST_NVHE_FLAGS;
|
|
|
|
params->vttbr = params->vtcr = 0;
|
2020-05-15 23:20:56 +08:00
|
|
|
|
2020-12-03 02:41:06 +08:00
|
|
|
/*
|
|
|
|
* Flush the init params from the data cache because the struct will
|
|
|
|
* be read while the MMU is off.
|
|
|
|
*/
|
|
|
|
kvm_flush_dcache_to_poc(params, sizeof(*params));
|
2021-03-19 18:01:12 +08:00
|
|
|
}
|
|
|
|
|
2021-03-19 18:01:26 +08:00
|
|
|
static void hyp_install_host_vector(void)
|
2021-03-19 18:01:12 +08:00
|
|
|
{
|
|
|
|
struct kvm_nvhe_init_params *params;
|
|
|
|
struct arm_smccc_res res;
|
|
|
|
|
|
|
|
/* Switch from the HYP stub to our own HYP init vector */
|
|
|
|
__hyp_set_vectors(kvm_get_idmap_vector());
|
2013-01-21 07:28:06 +08:00
|
|
|
|
2020-05-15 23:20:56 +08:00
|
|
|
/*
|
|
|
|
* Call initialization code, and switch to the full blown HYP code.
|
|
|
|
* If the cpucaps haven't been finalized yet, something has gone very
|
|
|
|
* wrong, and hyp will crash and burn when it uses any
|
|
|
|
* cpus_have_const_cap() wrapper.
|
|
|
|
*/
|
|
|
|
BUG_ON(!system_capabilities_finalized());
|
2021-03-19 18:01:12 +08:00
|
|
|
params = this_cpu_ptr_nvhe_sym(kvm_init_params);
|
2020-12-03 02:41:06 +08:00
|
|
|
arm_smccc_1_1_hvc(KVM_HOST_SMCCC_FUNC(__kvm_hyp_init), virt_to_phys(params), &res);
|
2020-09-15 18:46:42 +08:00
|
|
|
WARN_ON(res.a0 != SMCCC_RET_SUCCESS);
|
2021-03-19 18:01:26 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
static void cpu_init_hyp_mode(void)
|
|
|
|
{
|
|
|
|
hyp_install_host_vector();
|
2020-05-15 23:20:56 +08:00
|
|
|
|
|
|
|
/*
|
|
|
|
* Disabling SSBD on a non-VHE system requires us to enable SSBS
|
|
|
|
* at EL2.
|
|
|
|
*/
|
|
|
|
if (this_cpu_has_cap(ARM64_SSBS) &&
|
2020-09-18 21:08:54 +08:00
|
|
|
arm64_get_spectre_v4_state() == SPECTRE_VULNERABLE) {
|
2020-06-25 21:14:16 +08:00
|
|
|
kvm_call_hyp_nvhe(__kvm_enable_ssbs);
|
2020-05-15 23:20:56 +08:00
|
|
|
}
|
2013-01-21 07:28:06 +08:00
|
|
|
}
|
|
|
|
|
2017-04-04 02:38:01 +08:00
|
|
|
static void cpu_hyp_reset(void)
|
|
|
|
{
|
|
|
|
if (!is_kernel_in_hyp_mode())
|
|
|
|
__hyp_reset_vectors();
|
|
|
|
}
|
|
|
|
|
2020-11-13 19:38:40 +08:00
|
|
|
/*
|
|
|
|
* EL2 vectors can be mapped and rerouted in a number of ways,
|
|
|
|
* depending on the kernel configuration and CPU present:
|
|
|
|
*
|
|
|
|
* - If the CPU is affected by Spectre-v2, the hardening sequence is
|
|
|
|
* placed in one of the vector slots, which is executed before jumping
|
|
|
|
* to the real vectors.
|
|
|
|
*
|
2020-11-13 19:38:45 +08:00
|
|
|
* - If the CPU also has the ARM64_SPECTRE_V3A cap, the slot
|
2020-11-13 19:38:40 +08:00
|
|
|
* containing the hardening sequence is mapped next to the idmap page,
|
|
|
|
* and executed before jumping to the real vectors.
|
|
|
|
*
|
2020-11-13 19:38:45 +08:00
|
|
|
* - If the CPU only has the ARM64_SPECTRE_V3A cap, then an
|
2020-11-13 19:38:40 +08:00
|
|
|
* empty slot is selected, mapped next to the idmap page, and
|
|
|
|
* executed before jumping to the real vectors.
|
|
|
|
*
|
2020-11-13 19:38:45 +08:00
|
|
|
* Note that ARM64_SPECTRE_V3A is somewhat incompatible with
|
2020-11-13 19:38:40 +08:00
|
|
|
* VHE, as we don't have hypervisor-specific mappings. If the system
|
|
|
|
* is VHE and yet selects this capability, it will be ignored.
|
|
|
|
*/
|
|
|
|
static void cpu_set_hyp_vector(void)
|
|
|
|
{
|
2020-11-13 19:38:42 +08:00
|
|
|
struct bp_hardening_data *data = this_cpu_ptr(&bp_hardening_data);
|
2020-11-13 19:38:44 +08:00
|
|
|
void *vector = hyp_spectre_vector_selector[data->slot];
|
2020-11-13 19:38:40 +08:00
|
|
|
|
2021-03-19 18:01:26 +08:00
|
|
|
if (!is_protected_kvm_enabled())
|
|
|
|
*this_cpu_ptr_hyp_sym(kvm_hyp_vector) = (unsigned long)vector;
|
|
|
|
else
|
|
|
|
kvm_call_hyp_nvhe(__pkvm_cpu_set_vector, data->slot);
|
2020-11-13 19:38:40 +08:00
|
|
|
}
|
|
|
|
|
2021-10-08 21:58:36 +08:00
|
|
|
static void cpu_hyp_init_context(void)
|
2016-03-31 01:33:04 +08:00
|
|
|
{
|
2020-09-23 04:49:08 +08:00
|
|
|
kvm_init_host_cpu_context(&this_cpu_ptr_hyp_sym(kvm_host_data)->host_ctxt);
|
2019-07-06 06:35:56 +08:00
|
|
|
|
2021-10-08 21:58:36 +08:00
|
|
|
if (!is_kernel_in_hyp_mode())
|
2019-11-21 15:15:59 +08:00
|
|
|
cpu_init_hyp_mode();
|
2021-10-08 21:58:36 +08:00
|
|
|
}
|
2017-03-18 20:56:56 +08:00
|
|
|
|
2021-10-08 21:58:36 +08:00
|
|
|
static void cpu_hyp_init_features(void)
|
|
|
|
{
|
2021-03-19 18:01:26 +08:00
|
|
|
cpu_set_hyp_vector();
|
2018-10-18 00:42:10 +08:00
|
|
|
kvm_arm_init_debug();
|
2017-03-18 20:56:56 +08:00
|
|
|
|
2021-10-08 21:58:36 +08:00
|
|
|
if (is_kernel_in_hyp_mode())
|
|
|
|
kvm_timer_init_vhe();
|
|
|
|
|
2017-03-18 20:56:56 +08:00
|
|
|
if (vgic_present)
|
|
|
|
kvm_vgic_init_cpu_hardware();
|
2016-03-31 01:33:04 +08:00
|
|
|
}
|
|
|
|
|
2021-10-08 21:58:36 +08:00
|
|
|
static void cpu_hyp_reinit(void)
|
|
|
|
{
|
|
|
|
cpu_hyp_reset();
|
|
|
|
cpu_hyp_init_context();
|
|
|
|
cpu_hyp_init_features();
|
|
|
|
}
|
|
|
|
|
arm64: kvm: allows kvm cpu hotplug
The current kvm implementation on arm64 does cpu-specific initialization
at system boot, and has no way to gracefully shutdown a core in terms of
kvm. This prevents kexec from rebooting the system at EL2.
This patch adds a cpu tear-down function and also puts an existing cpu-init
code into a separate function, kvm_arch_hardware_disable() and
kvm_arch_hardware_enable() respectively.
We don't need the arm64 specific cpu hotplug hook any more.
Since this patch modifies common code between arm and arm64, one stub
definition, __cpu_reset_hyp_mode(), is added on arm side to avoid
compilation errors.
Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
[Rebase, added separate VHE init/exit path, changed resets use of
kvm_call_hyp() to the __version, en/disabled hardware in init_subsystems(),
added icache maintenance to __kvm_hyp_reset() and removed lr restore, removed
guest-enter after teardown handling]
Signed-off-by: James Morse <james.morse@arm.com>
Acked-by: Marc Zyngier <marc.zyngier@arm.com>
Signed-off-by: Will Deacon <will.deacon@arm.com>
2016-04-28 00:47:05 +08:00
|
|
|
static void _kvm_arch_hardware_enable(void *discard)
|
|
|
|
{
|
|
|
|
if (!__this_cpu_read(kvm_arm_hardware_enabled)) {
|
2016-03-31 01:33:04 +08:00
|
|
|
cpu_hyp_reinit();
|
arm64: kvm: allows kvm cpu hotplug
The current kvm implementation on arm64 does cpu-specific initialization
at system boot, and has no way to gracefully shutdown a core in terms of
kvm. This prevents kexec from rebooting the system at EL2.
This patch adds a cpu tear-down function and also puts an existing cpu-init
code into a separate function, kvm_arch_hardware_disable() and
kvm_arch_hardware_enable() respectively.
We don't need the arm64 specific cpu hotplug hook any more.
Since this patch modifies common code between arm and arm64, one stub
definition, __cpu_reset_hyp_mode(), is added on arm side to avoid
compilation errors.
Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
[Rebase, added separate VHE init/exit path, changed resets use of
kvm_call_hyp() to the __version, en/disabled hardware in init_subsystems(),
added icache maintenance to __kvm_hyp_reset() and removed lr restore, removed
guest-enter after teardown handling]
Signed-off-by: James Morse <james.morse@arm.com>
Acked-by: Marc Zyngier <marc.zyngier@arm.com>
Signed-off-by: Will Deacon <will.deacon@arm.com>
2016-04-28 00:47:05 +08:00
|
|
|
__this_cpu_write(kvm_arm_hardware_enabled, 1);
|
2013-04-13 02:12:07 +08:00
|
|
|
}
|
arm64: kvm: allows kvm cpu hotplug
The current kvm implementation on arm64 does cpu-specific initialization
at system boot, and has no way to gracefully shutdown a core in terms of
kvm. This prevents kexec from rebooting the system at EL2.
This patch adds a cpu tear-down function and also puts an existing cpu-init
code into a separate function, kvm_arch_hardware_disable() and
kvm_arch_hardware_enable() respectively.
We don't need the arm64 specific cpu hotplug hook any more.
Since this patch modifies common code between arm and arm64, one stub
definition, __cpu_reset_hyp_mode(), is added on arm side to avoid
compilation errors.
Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
[Rebase, added separate VHE init/exit path, changed resets use of
kvm_call_hyp() to the __version, en/disabled hardware in init_subsystems(),
added icache maintenance to __kvm_hyp_reset() and removed lr restore, removed
guest-enter after teardown handling]
Signed-off-by: James Morse <james.morse@arm.com>
Acked-by: Marc Zyngier <marc.zyngier@arm.com>
Signed-off-by: Will Deacon <will.deacon@arm.com>
2016-04-28 00:47:05 +08:00
|
|
|
}
|
2013-04-13 02:12:07 +08:00
|
|
|
|
arm64: kvm: allows kvm cpu hotplug
The current kvm implementation on arm64 does cpu-specific initialization
at system boot, and has no way to gracefully shutdown a core in terms of
kvm. This prevents kexec from rebooting the system at EL2.
This patch adds a cpu tear-down function and also puts an existing cpu-init
code into a separate function, kvm_arch_hardware_disable() and
kvm_arch_hardware_enable() respectively.
We don't need the arm64 specific cpu hotplug hook any more.
Since this patch modifies common code between arm and arm64, one stub
definition, __cpu_reset_hyp_mode(), is added on arm side to avoid
compilation errors.
Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
[Rebase, added separate VHE init/exit path, changed resets use of
kvm_call_hyp() to the __version, en/disabled hardware in init_subsystems(),
added icache maintenance to __kvm_hyp_reset() and removed lr restore, removed
guest-enter after teardown handling]
Signed-off-by: James Morse <james.morse@arm.com>
Acked-by: Marc Zyngier <marc.zyngier@arm.com>
Signed-off-by: Will Deacon <will.deacon@arm.com>
2016-04-28 00:47:05 +08:00
|
|
|
int kvm_arch_hardware_enable(void)
|
|
|
|
{
|
|
|
|
_kvm_arch_hardware_enable(NULL);
|
|
|
|
return 0;
|
2013-01-21 07:28:06 +08:00
|
|
|
}
|
|
|
|
|
arm64: kvm: allows kvm cpu hotplug
The current kvm implementation on arm64 does cpu-specific initialization
at system boot, and has no way to gracefully shutdown a core in terms of
kvm. This prevents kexec from rebooting the system at EL2.
This patch adds a cpu tear-down function and also puts an existing cpu-init
code into a separate function, kvm_arch_hardware_disable() and
kvm_arch_hardware_enable() respectively.
We don't need the arm64 specific cpu hotplug hook any more.
Since this patch modifies common code between arm and arm64, one stub
definition, __cpu_reset_hyp_mode(), is added on arm side to avoid
compilation errors.
Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
[Rebase, added separate VHE init/exit path, changed resets use of
kvm_call_hyp() to the __version, en/disabled hardware in init_subsystems(),
added icache maintenance to __kvm_hyp_reset() and removed lr restore, removed
guest-enter after teardown handling]
Signed-off-by: James Morse <james.morse@arm.com>
Acked-by: Marc Zyngier <marc.zyngier@arm.com>
Signed-off-by: Will Deacon <will.deacon@arm.com>
2016-04-28 00:47:05 +08:00
|
|
|
static void _kvm_arch_hardware_disable(void *discard)
|
|
|
|
{
|
|
|
|
if (__this_cpu_read(kvm_arm_hardware_enabled)) {
|
|
|
|
cpu_hyp_reset();
|
|
|
|
__this_cpu_write(kvm_arm_hardware_enabled, 0);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
void kvm_arch_hardware_disable(void)
|
|
|
|
{
|
2020-12-03 02:41:20 +08:00
|
|
|
if (!is_protected_kvm_enabled())
|
|
|
|
_kvm_arch_hardware_disable(NULL);
|
arm64: kvm: allows kvm cpu hotplug
The current kvm implementation on arm64 does cpu-specific initialization
at system boot, and has no way to gracefully shutdown a core in terms of
kvm. This prevents kexec from rebooting the system at EL2.
This patch adds a cpu tear-down function and also puts an existing cpu-init
code into a separate function, kvm_arch_hardware_disable() and
kvm_arch_hardware_enable() respectively.
We don't need the arm64 specific cpu hotplug hook any more.
Since this patch modifies common code between arm and arm64, one stub
definition, __cpu_reset_hyp_mode(), is added on arm side to avoid
compilation errors.
Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
[Rebase, added separate VHE init/exit path, changed resets use of
kvm_call_hyp() to the __version, en/disabled hardware in init_subsystems(),
added icache maintenance to __kvm_hyp_reset() and removed lr restore, removed
guest-enter after teardown handling]
Signed-off-by: James Morse <james.morse@arm.com>
Acked-by: Marc Zyngier <marc.zyngier@arm.com>
Signed-off-by: Will Deacon <will.deacon@arm.com>
2016-04-28 00:47:05 +08:00
|
|
|
}
|
2013-04-13 02:12:07 +08:00
|
|
|
|
2013-08-05 22:04:46 +08:00
|
|
|
#ifdef CONFIG_CPU_PM
|
|
|
|
static int hyp_init_cpu_pm_notifier(struct notifier_block *self,
|
|
|
|
unsigned long cmd,
|
|
|
|
void *v)
|
|
|
|
{
|
arm64: kvm: allows kvm cpu hotplug
The current kvm implementation on arm64 does cpu-specific initialization
at system boot, and has no way to gracefully shutdown a core in terms of
kvm. This prevents kexec from rebooting the system at EL2.
This patch adds a cpu tear-down function and also puts an existing cpu-init
code into a separate function, kvm_arch_hardware_disable() and
kvm_arch_hardware_enable() respectively.
We don't need the arm64 specific cpu hotplug hook any more.
Since this patch modifies common code between arm and arm64, one stub
definition, __cpu_reset_hyp_mode(), is added on arm side to avoid
compilation errors.
Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
[Rebase, added separate VHE init/exit path, changed resets use of
kvm_call_hyp() to the __version, en/disabled hardware in init_subsystems(),
added icache maintenance to __kvm_hyp_reset() and removed lr restore, removed
guest-enter after teardown handling]
Signed-off-by: James Morse <james.morse@arm.com>
Acked-by: Marc Zyngier <marc.zyngier@arm.com>
Signed-off-by: Will Deacon <will.deacon@arm.com>
2016-04-28 00:47:05 +08:00
|
|
|
/*
|
|
|
|
* kvm_arm_hardware_enabled is left with its old value over
|
|
|
|
* PM_ENTER->PM_EXIT. It is used to indicate PM_EXIT should
|
|
|
|
* re-enable hyp.
|
|
|
|
*/
|
|
|
|
switch (cmd) {
|
|
|
|
case CPU_PM_ENTER:
|
|
|
|
if (__this_cpu_read(kvm_arm_hardware_enabled))
|
|
|
|
/*
|
|
|
|
* don't update kvm_arm_hardware_enabled here
|
|
|
|
* so that the hardware will be re-enabled
|
|
|
|
* when we resume. See below.
|
|
|
|
*/
|
|
|
|
cpu_hyp_reset();
|
|
|
|
|
2013-08-05 22:04:46 +08:00
|
|
|
return NOTIFY_OK;
|
2018-01-23 02:19:06 +08:00
|
|
|
case CPU_PM_ENTER_FAILED:
|
arm64: kvm: allows kvm cpu hotplug
The current kvm implementation on arm64 does cpu-specific initialization
at system boot, and has no way to gracefully shutdown a core in terms of
kvm. This prevents kexec from rebooting the system at EL2.
This patch adds a cpu tear-down function and also puts an existing cpu-init
code into a separate function, kvm_arch_hardware_disable() and
kvm_arch_hardware_enable() respectively.
We don't need the arm64 specific cpu hotplug hook any more.
Since this patch modifies common code between arm and arm64, one stub
definition, __cpu_reset_hyp_mode(), is added on arm side to avoid
compilation errors.
Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
[Rebase, added separate VHE init/exit path, changed resets use of
kvm_call_hyp() to the __version, en/disabled hardware in init_subsystems(),
added icache maintenance to __kvm_hyp_reset() and removed lr restore, removed
guest-enter after teardown handling]
Signed-off-by: James Morse <james.morse@arm.com>
Acked-by: Marc Zyngier <marc.zyngier@arm.com>
Signed-off-by: Will Deacon <will.deacon@arm.com>
2016-04-28 00:47:05 +08:00
|
|
|
case CPU_PM_EXIT:
|
|
|
|
if (__this_cpu_read(kvm_arm_hardware_enabled))
|
|
|
|
/* The hardware was enabled before suspend. */
|
|
|
|
cpu_hyp_reinit();
|
2013-08-05 22:04:46 +08:00
|
|
|
|
arm64: kvm: allows kvm cpu hotplug
The current kvm implementation on arm64 does cpu-specific initialization
at system boot, and has no way to gracefully shutdown a core in terms of
kvm. This prevents kexec from rebooting the system at EL2.
This patch adds a cpu tear-down function and also puts an existing cpu-init
code into a separate function, kvm_arch_hardware_disable() and
kvm_arch_hardware_enable() respectively.
We don't need the arm64 specific cpu hotplug hook any more.
Since this patch modifies common code between arm and arm64, one stub
definition, __cpu_reset_hyp_mode(), is added on arm side to avoid
compilation errors.
Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
[Rebase, added separate VHE init/exit path, changed resets use of
kvm_call_hyp() to the __version, en/disabled hardware in init_subsystems(),
added icache maintenance to __kvm_hyp_reset() and removed lr restore, removed
guest-enter after teardown handling]
Signed-off-by: James Morse <james.morse@arm.com>
Acked-by: Marc Zyngier <marc.zyngier@arm.com>
Signed-off-by: Will Deacon <will.deacon@arm.com>
2016-04-28 00:47:05 +08:00
|
|
|
return NOTIFY_OK;
|
|
|
|
|
|
|
|
default:
|
|
|
|
return NOTIFY_DONE;
|
|
|
|
}
|
2013-08-05 22:04:46 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
static struct notifier_block hyp_init_cpu_pm_nb = {
|
|
|
|
.notifier_call = hyp_init_cpu_pm_notifier,
|
|
|
|
};
|
|
|
|
|
2020-12-23 20:08:54 +08:00
|
|
|
static void hyp_cpu_pm_init(void)
|
2013-08-05 22:04:46 +08:00
|
|
|
{
|
2020-12-03 02:41:20 +08:00
|
|
|
if (!is_protected_kvm_enabled())
|
|
|
|
cpu_pm_register_notifier(&hyp_init_cpu_pm_nb);
|
2013-08-05 22:04:46 +08:00
|
|
|
}
|
2020-12-23 20:08:54 +08:00
|
|
|
static void hyp_cpu_pm_exit(void)
|
2016-04-04 21:46:51 +08:00
|
|
|
{
|
2020-12-03 02:41:20 +08:00
|
|
|
if (!is_protected_kvm_enabled())
|
|
|
|
cpu_pm_unregister_notifier(&hyp_init_cpu_pm_nb);
|
2016-04-04 21:46:51 +08:00
|
|
|
}
|
2013-08-05 22:04:46 +08:00
|
|
|
#else
|
|
|
|
static inline void hyp_cpu_pm_init(void)
|
|
|
|
{
|
|
|
|
}
|
2016-04-04 21:46:51 +08:00
|
|
|
static inline void hyp_cpu_pm_exit(void)
|
|
|
|
{
|
|
|
|
}
|
2013-08-05 22:04:46 +08:00
|
|
|
#endif
|
|
|
|
|
2020-12-03 02:41:10 +08:00
|
|
|
static void init_cpu_logical_map(void)
|
|
|
|
{
|
|
|
|
unsigned int cpu;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Copy the MPIDR <-> logical CPU ID mapping to hyp.
|
2022-03-18 18:37:19 +08:00
|
|
|
* Only copy the set of online CPUs whose features have been checked
|
2020-12-03 02:41:10 +08:00
|
|
|
* against the finalized system capabilities. The hypervisor will not
|
|
|
|
* allow any other CPUs from the `possible` set to boot.
|
|
|
|
*/
|
|
|
|
for_each_online_cpu(cpu)
|
2020-12-08 22:24:50 +08:00
|
|
|
hyp_cpu_logical_map[cpu] = cpu_logical_map(cpu);
|
2020-12-03 02:41:10 +08:00
|
|
|
}
|
|
|
|
|
2020-12-22 20:46:41 +08:00
|
|
|
#define init_psci_0_1_impl_state(config, what) \
|
|
|
|
config.psci_0_1_ ## what ## _implemented = psci_ops.what
|
|
|
|
|
2020-12-03 02:41:12 +08:00
|
|
|
static bool init_psci_relay(void)
|
|
|
|
{
|
|
|
|
/*
|
|
|
|
* If PSCI has not been initialized, protected KVM cannot install
|
|
|
|
* itself on newly booted CPUs.
|
|
|
|
*/
|
|
|
|
if (!psci_ops.get_version) {
|
|
|
|
kvm_err("Cannot initialize protected mode without PSCI\n");
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
|
2020-12-08 22:24:47 +08:00
|
|
|
kvm_host_psci_config.version = psci_ops.get_version();
|
|
|
|
|
|
|
|
if (kvm_host_psci_config.version == PSCI_VERSION(0, 1)) {
|
|
|
|
kvm_host_psci_config.function_ids_0_1 = get_psci_0_1_function_ids();
|
2020-12-22 20:46:41 +08:00
|
|
|
init_psci_0_1_impl_state(kvm_host_psci_config, cpu_suspend);
|
|
|
|
init_psci_0_1_impl_state(kvm_host_psci_config, cpu_on);
|
|
|
|
init_psci_0_1_impl_state(kvm_host_psci_config, cpu_off);
|
|
|
|
init_psci_0_1_impl_state(kvm_host_psci_config, migrate);
|
2020-12-08 22:24:47 +08:00
|
|
|
}
|
2020-12-03 02:41:12 +08:00
|
|
|
return true;
|
|
|
|
}
|
|
|
|
|
2015-01-29 19:59:54 +08:00
|
|
|
static int init_subsystems(void)
|
|
|
|
{
|
arm64: kvm: allows kvm cpu hotplug
The current kvm implementation on arm64 does cpu-specific initialization
at system boot, and has no way to gracefully shutdown a core in terms of
kvm. This prevents kexec from rebooting the system at EL2.
This patch adds a cpu tear-down function and also puts an existing cpu-init
code into a separate function, kvm_arch_hardware_disable() and
kvm_arch_hardware_enable() respectively.
We don't need the arm64 specific cpu hotplug hook any more.
Since this patch modifies common code between arm and arm64, one stub
definition, __cpu_reset_hyp_mode(), is added on arm side to avoid
compilation errors.
Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
[Rebase, added separate VHE init/exit path, changed resets use of
kvm_call_hyp() to the __version, en/disabled hardware in init_subsystems(),
added icache maintenance to __kvm_hyp_reset() and removed lr restore, removed
guest-enter after teardown handling]
Signed-off-by: James Morse <james.morse@arm.com>
Acked-by: Marc Zyngier <marc.zyngier@arm.com>
Signed-off-by: Will Deacon <will.deacon@arm.com>
2016-04-28 00:47:05 +08:00
|
|
|
int err = 0;
|
2015-01-29 19:59:54 +08:00
|
|
|
|
2016-03-31 01:33:04 +08:00
|
|
|
/*
|
arm64: kvm: allows kvm cpu hotplug
The current kvm implementation on arm64 does cpu-specific initialization
at system boot, and has no way to gracefully shutdown a core in terms of
kvm. This prevents kexec from rebooting the system at EL2.
This patch adds a cpu tear-down function and also puts an existing cpu-init
code into a separate function, kvm_arch_hardware_disable() and
kvm_arch_hardware_enable() respectively.
We don't need the arm64 specific cpu hotplug hook any more.
Since this patch modifies common code between arm and arm64, one stub
definition, __cpu_reset_hyp_mode(), is added on arm side to avoid
compilation errors.
Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
[Rebase, added separate VHE init/exit path, changed resets use of
kvm_call_hyp() to the __version, en/disabled hardware in init_subsystems(),
added icache maintenance to __kvm_hyp_reset() and removed lr restore, removed
guest-enter after teardown handling]
Signed-off-by: James Morse <james.morse@arm.com>
Acked-by: Marc Zyngier <marc.zyngier@arm.com>
Signed-off-by: Will Deacon <will.deacon@arm.com>
2016-04-28 00:47:05 +08:00
|
|
|
* Enable hardware so that subsystem initialisation can access EL2.
|
2016-03-31 01:33:04 +08:00
|
|
|
*/
|
arm64: kvm: allows kvm cpu hotplug
The current kvm implementation on arm64 does cpu-specific initialization
at system boot, and has no way to gracefully shutdown a core in terms of
kvm. This prevents kexec from rebooting the system at EL2.
This patch adds a cpu tear-down function and also puts an existing cpu-init
code into a separate function, kvm_arch_hardware_disable() and
kvm_arch_hardware_enable() respectively.
We don't need the arm64 specific cpu hotplug hook any more.
Since this patch modifies common code between arm and arm64, one stub
definition, __cpu_reset_hyp_mode(), is added on arm side to avoid
compilation errors.
Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
[Rebase, added separate VHE init/exit path, changed resets use of
kvm_call_hyp() to the __version, en/disabled hardware in init_subsystems(),
added icache maintenance to __kvm_hyp_reset() and removed lr restore, removed
guest-enter after teardown handling]
Signed-off-by: James Morse <james.morse@arm.com>
Acked-by: Marc Zyngier <marc.zyngier@arm.com>
Signed-off-by: Will Deacon <will.deacon@arm.com>
2016-04-28 00:47:05 +08:00
|
|
|
on_each_cpu(_kvm_arch_hardware_enable, NULL, 1);
|
2016-03-31 01:33:04 +08:00
|
|
|
|
|
|
|
/*
|
|
|
|
* Register CPU lower-power notifier
|
|
|
|
*/
|
|
|
|
hyp_cpu_pm_init();
|
|
|
|
|
2015-01-29 19:59:54 +08:00
|
|
|
/*
|
|
|
|
* Init HYP view of VGIC
|
|
|
|
*/
|
|
|
|
err = kvm_vgic_hyp_init();
|
|
|
|
switch (err) {
|
|
|
|
case 0:
|
|
|
|
vgic_present = true;
|
|
|
|
break;
|
|
|
|
case -ENODEV:
|
|
|
|
case -ENXIO:
|
|
|
|
vgic_present = false;
|
arm64: kvm: allows kvm cpu hotplug
The current kvm implementation on arm64 does cpu-specific initialization
at system boot, and has no way to gracefully shutdown a core in terms of
kvm. This prevents kexec from rebooting the system at EL2.
This patch adds a cpu tear-down function and also puts an existing cpu-init
code into a separate function, kvm_arch_hardware_disable() and
kvm_arch_hardware_enable() respectively.
We don't need the arm64 specific cpu hotplug hook any more.
Since this patch modifies common code between arm and arm64, one stub
definition, __cpu_reset_hyp_mode(), is added on arm side to avoid
compilation errors.
Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
[Rebase, added separate VHE init/exit path, changed resets use of
kvm_call_hyp() to the __version, en/disabled hardware in init_subsystems(),
added icache maintenance to __kvm_hyp_reset() and removed lr restore, removed
guest-enter after teardown handling]
Signed-off-by: James Morse <james.morse@arm.com>
Acked-by: Marc Zyngier <marc.zyngier@arm.com>
Signed-off-by: Will Deacon <will.deacon@arm.com>
2016-04-28 00:47:05 +08:00
|
|
|
err = 0;
|
2015-01-29 19:59:54 +08:00
|
|
|
break;
|
|
|
|
default:
|
arm64: kvm: allows kvm cpu hotplug
The current kvm implementation on arm64 does cpu-specific initialization
at system boot, and has no way to gracefully shutdown a core in terms of
kvm. This prevents kexec from rebooting the system at EL2.
This patch adds a cpu tear-down function and also puts an existing cpu-init
code into a separate function, kvm_arch_hardware_disable() and
kvm_arch_hardware_enable() respectively.
We don't need the arm64 specific cpu hotplug hook any more.
Since this patch modifies common code between arm and arm64, one stub
definition, __cpu_reset_hyp_mode(), is added on arm side to avoid
compilation errors.
Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
[Rebase, added separate VHE init/exit path, changed resets use of
kvm_call_hyp() to the __version, en/disabled hardware in init_subsystems(),
added icache maintenance to __kvm_hyp_reset() and removed lr restore, removed
guest-enter after teardown handling]
Signed-off-by: James Morse <james.morse@arm.com>
Acked-by: Marc Zyngier <marc.zyngier@arm.com>
Signed-off-by: Will Deacon <will.deacon@arm.com>
2016-04-28 00:47:05 +08:00
|
|
|
goto out;
|
2015-01-29 19:59:54 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Init HYP architected timer support
|
|
|
|
*/
|
2017-12-07 19:46:15 +08:00
|
|
|
err = kvm_timer_hyp_init(vgic_present);
|
2015-01-29 19:59:54 +08:00
|
|
|
if (err)
|
arm64: kvm: allows kvm cpu hotplug
The current kvm implementation on arm64 does cpu-specific initialization
at system boot, and has no way to gracefully shutdown a core in terms of
kvm. This prevents kexec from rebooting the system at EL2.
This patch adds a cpu tear-down function and also puts an existing cpu-init
code into a separate function, kvm_arch_hardware_disable() and
kvm_arch_hardware_enable() respectively.
We don't need the arm64 specific cpu hotplug hook any more.
Since this patch modifies common code between arm and arm64, one stub
definition, __cpu_reset_hyp_mode(), is added on arm side to avoid
compilation errors.
Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
[Rebase, added separate VHE init/exit path, changed resets use of
kvm_call_hyp() to the __version, en/disabled hardware in init_subsystems(),
added icache maintenance to __kvm_hyp_reset() and removed lr restore, removed
guest-enter after teardown handling]
Signed-off-by: James Morse <james.morse@arm.com>
Acked-by: Marc Zyngier <marc.zyngier@arm.com>
Signed-off-by: Will Deacon <will.deacon@arm.com>
2016-04-28 00:47:05 +08:00
|
|
|
goto out;
|
2015-01-29 19:59:54 +08:00
|
|
|
|
2021-11-11 10:07:37 +08:00
|
|
|
kvm_register_perf_callbacks(NULL);
|
|
|
|
|
arm64: kvm: allows kvm cpu hotplug
The current kvm implementation on arm64 does cpu-specific initialization
at system boot, and has no way to gracefully shutdown a core in terms of
kvm. This prevents kexec from rebooting the system at EL2.
This patch adds a cpu tear-down function and also puts an existing cpu-init
code into a separate function, kvm_arch_hardware_disable() and
kvm_arch_hardware_enable() respectively.
We don't need the arm64 specific cpu hotplug hook any more.
Since this patch modifies common code between arm and arm64, one stub
definition, __cpu_reset_hyp_mode(), is added on arm side to avoid
compilation errors.
Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
[Rebase, added separate VHE init/exit path, changed resets use of
kvm_call_hyp() to the __version, en/disabled hardware in init_subsystems(),
added icache maintenance to __kvm_hyp_reset() and removed lr restore, removed
guest-enter after teardown handling]
Signed-off-by: James Morse <james.morse@arm.com>
Acked-by: Marc Zyngier <marc.zyngier@arm.com>
Signed-off-by: Will Deacon <will.deacon@arm.com>
2016-04-28 00:47:05 +08:00
|
|
|
out:
|
2020-12-03 02:41:20 +08:00
|
|
|
if (err || !is_protected_kvm_enabled())
|
|
|
|
on_each_cpu(_kvm_arch_hardware_disable, NULL, 1);
|
arm64: kvm: allows kvm cpu hotplug
The current kvm implementation on arm64 does cpu-specific initialization
at system boot, and has no way to gracefully shutdown a core in terms of
kvm. This prevents kexec from rebooting the system at EL2.
This patch adds a cpu tear-down function and also puts an existing cpu-init
code into a separate function, kvm_arch_hardware_disable() and
kvm_arch_hardware_enable() respectively.
We don't need the arm64 specific cpu hotplug hook any more.
Since this patch modifies common code between arm and arm64, one stub
definition, __cpu_reset_hyp_mode(), is added on arm side to avoid
compilation errors.
Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
[Rebase, added separate VHE init/exit path, changed resets use of
kvm_call_hyp() to the __version, en/disabled hardware in init_subsystems(),
added icache maintenance to __kvm_hyp_reset() and removed lr restore, removed
guest-enter after teardown handling]
Signed-off-by: James Morse <james.morse@arm.com>
Acked-by: Marc Zyngier <marc.zyngier@arm.com>
Signed-off-by: Will Deacon <will.deacon@arm.com>
2016-04-28 00:47:05 +08:00
|
|
|
|
|
|
|
return err;
|
2015-01-29 19:59:54 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
static void teardown_hyp_mode(void)
|
|
|
|
{
|
|
|
|
int cpu;
|
|
|
|
|
|
|
|
free_hyp_pgds();
|
2020-09-23 04:49:09 +08:00
|
|
|
for_each_possible_cpu(cpu) {
|
2015-01-29 19:59:54 +08:00
|
|
|
free_page(per_cpu(kvm_arm_hyp_stack_page, cpu));
|
2020-09-23 04:49:09 +08:00
|
|
|
free_pages(kvm_arm_hyp_percpu_base[cpu], nvhe_percpu_order());
|
|
|
|
}
|
2015-01-29 19:59:54 +08:00
|
|
|
}
|
|
|
|
|
2021-03-19 18:01:26 +08:00
|
|
|
static int do_pkvm_init(u32 hyp_va_bits)
|
|
|
|
{
|
|
|
|
void *per_cpu_base = kvm_ksym_ref(kvm_arm_hyp_percpu_base);
|
|
|
|
int ret;
|
|
|
|
|
|
|
|
preempt_disable();
|
2021-10-08 21:58:36 +08:00
|
|
|
cpu_hyp_init_context();
|
2021-03-19 18:01:26 +08:00
|
|
|
ret = kvm_call_hyp_nvhe(__pkvm_init, hyp_mem_base, hyp_mem_size,
|
|
|
|
num_possible_cpus(), kern_hyp_va(per_cpu_base),
|
|
|
|
hyp_va_bits);
|
2021-10-08 21:58:36 +08:00
|
|
|
cpu_hyp_init_features();
|
|
|
|
|
|
|
|
/*
|
|
|
|
* The stub hypercalls are now disabled, so set our local flag to
|
|
|
|
* prevent a later re-init attempt in kvm_arch_hardware_enable().
|
|
|
|
*/
|
|
|
|
__this_cpu_write(kvm_arm_hardware_enabled, 1);
|
2021-03-19 18:01:26 +08:00
|
|
|
preempt_enable();
|
|
|
|
|
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
|
|
|
|
static int kvm_hyp_init_protection(u32 hyp_va_bits)
|
|
|
|
{
|
|
|
|
void *addr = phys_to_virt(hyp_mem_base);
|
|
|
|
int ret;
|
|
|
|
|
2021-10-10 22:56:32 +08:00
|
|
|
kvm_nvhe_sym(id_aa64pfr0_el1_sys_val) = read_sanitised_ftr_reg(SYS_ID_AA64PFR0_EL1);
|
|
|
|
kvm_nvhe_sym(id_aa64pfr1_el1_sys_val) = read_sanitised_ftr_reg(SYS_ID_AA64PFR1_EL1);
|
|
|
|
kvm_nvhe_sym(id_aa64isar0_el1_sys_val) = read_sanitised_ftr_reg(SYS_ID_AA64ISAR0_EL1);
|
|
|
|
kvm_nvhe_sym(id_aa64isar1_el1_sys_val) = read_sanitised_ftr_reg(SYS_ID_AA64ISAR1_EL1);
|
2022-02-24 20:49:52 +08:00
|
|
|
kvm_nvhe_sym(id_aa64isar2_el1_sys_val) = read_sanitised_ftr_reg(SYS_ID_AA64ISAR2_EL1);
|
2021-03-22 21:32:34 +08:00
|
|
|
kvm_nvhe_sym(id_aa64mmfr0_el1_sys_val) = read_sanitised_ftr_reg(SYS_ID_AA64MMFR0_EL1);
|
|
|
|
kvm_nvhe_sym(id_aa64mmfr1_el1_sys_val) = read_sanitised_ftr_reg(SYS_ID_AA64MMFR1_EL1);
|
2021-10-10 22:56:32 +08:00
|
|
|
kvm_nvhe_sym(id_aa64mmfr2_el1_sys_val) = read_sanitised_ftr_reg(SYS_ID_AA64MMFR2_EL1);
|
2021-03-22 21:32:34 +08:00
|
|
|
|
2021-03-19 18:01:26 +08:00
|
|
|
ret = create_hyp_mappings(addr, addr + hyp_mem_size, PAGE_HYP);
|
|
|
|
if (ret)
|
|
|
|
return ret;
|
|
|
|
|
|
|
|
ret = do_pkvm_init(hyp_va_bits);
|
|
|
|
if (ret)
|
|
|
|
return ret;
|
|
|
|
|
|
|
|
free_hyp_pgds();
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2013-01-21 07:28:06 +08:00
|
|
|
/**
|
|
|
|
* Inits Hyp-mode on all online CPUs
|
|
|
|
*/
|
|
|
|
static int init_hyp_mode(void)
|
|
|
|
{
|
2021-03-19 18:01:26 +08:00
|
|
|
u32 hyp_va_bits;
|
2013-01-21 07:28:06 +08:00
|
|
|
int cpu;
|
2021-03-19 18:01:26 +08:00
|
|
|
int err = -ENOMEM;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* The protected Hyp-mode cannot be initialized if the memory pool
|
|
|
|
* allocation has failed.
|
|
|
|
*/
|
|
|
|
if (is_protected_kvm_enabled() && !hyp_mem_base)
|
|
|
|
goto out_err;
|
2013-01-21 07:28:06 +08:00
|
|
|
|
|
|
|
/*
|
|
|
|
* Allocate Hyp PGD and setup Hyp identity mapping
|
|
|
|
*/
|
2021-03-19 18:01:26 +08:00
|
|
|
err = kvm_mmu_init(&hyp_va_bits);
|
2013-01-21 07:28:06 +08:00
|
|
|
if (err)
|
|
|
|
goto out_err;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Allocate stack pages for Hypervisor-mode
|
|
|
|
*/
|
|
|
|
for_each_possible_cpu(cpu) {
|
|
|
|
unsigned long stack_page;
|
|
|
|
|
|
|
|
stack_page = __get_free_page(GFP_KERNEL);
|
|
|
|
if (!stack_page) {
|
|
|
|
err = -ENOMEM;
|
2015-01-29 19:59:54 +08:00
|
|
|
goto out_err;
|
2013-01-21 07:28:06 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
per_cpu(kvm_arm_hyp_stack_page, cpu) = stack_page;
|
|
|
|
}
|
|
|
|
|
2020-09-23 04:49:09 +08:00
|
|
|
/*
|
|
|
|
* Allocate and initialize pages for Hypervisor-mode percpu regions.
|
|
|
|
*/
|
|
|
|
for_each_possible_cpu(cpu) {
|
|
|
|
struct page *page;
|
|
|
|
void *page_addr;
|
|
|
|
|
|
|
|
page = alloc_pages(GFP_KERNEL, nvhe_percpu_order());
|
|
|
|
if (!page) {
|
|
|
|
err = -ENOMEM;
|
|
|
|
goto out_err;
|
|
|
|
}
|
|
|
|
|
|
|
|
page_addr = page_address(page);
|
|
|
|
memcpy(page_addr, CHOOSE_NVHE_SYM(__per_cpu_start), nvhe_percpu_size());
|
|
|
|
kvm_arm_hyp_percpu_base[cpu] = (unsigned long)page_addr;
|
|
|
|
}
|
|
|
|
|
2013-01-21 07:28:06 +08:00
|
|
|
/*
|
|
|
|
* Map the Hyp-code called directly from the host
|
|
|
|
*/
|
arm64 updates for 4.6:
- Initial page table creation reworked to avoid breaking large block
mappings (huge pages) into smaller ones. The ARM architecture requires
break-before-make in such cases to avoid TLB conflicts but that's not
always possible on live page tables
- Kernel virtual memory layout: the kernel image is no longer linked to
the bottom of the linear mapping (PAGE_OFFSET) but at the bottom of
the vmalloc space, allowing the kernel to be loaded (nearly) anywhere
in physical RAM
- Kernel ASLR: position independent kernel Image and modules being
randomly mapped in the vmalloc space with the randomness is provided
by UEFI (efi_get_random_bytes() patches merged via the arm64 tree,
acked by Matt Fleming)
- Implement relative exception tables for arm64, required by KASLR
(initial code for ARCH_HAS_RELATIVE_EXTABLE added to lib/extable.c but
actual x86 conversion to deferred to 4.7 because of the merge
dependencies)
- Support for the User Access Override feature of ARMv8.2: this allows
uaccess functions (get_user etc.) to be implemented using LDTR/STTR
instructions. Such instructions, when run by the kernel, perform
unprivileged accesses adding an extra level of protection. The
set_fs() macro is used to "upgrade" such instruction to privileged
accesses via the UAO bit
- Half-precision floating point support (part of ARMv8.2)
- Optimisations for CPUs with or without a hardware prefetcher (using
run-time code patching)
- copy_page performance improvement to deal with 128 bytes at a time
- Sanity checks on the CPU capabilities (via CPUID) to prevent
incompatible secondary CPUs from being brought up (e.g. weird
big.LITTLE configurations)
- valid_user_regs() reworked for better sanity check of the sigcontext
information (restored pstate information)
- ACPI parking protocol implementation
- CONFIG_DEBUG_RODATA enabled by default
- VDSO code marked as read-only
- DEBUG_PAGEALLOC support
- ARCH_HAS_UBSAN_SANITIZE_ALL enabled
- Erratum workaround Cavium ThunderX SoC
- set_pte_at() fix for PROT_NONE mappings
- Code clean-ups
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQIcBAABAgAGBQJW6u95AAoJEGvWsS0AyF7xMyoP/3x2O6bgreSQ84BdO4JChN4+
RQ9OVdX8u2ItO9sgaCY2AA6KoiBuEjGmPl/XRuK0I7DpODTtRjEXQHuNNhz8AelC
hn4AEVqamY6Z5BzHFIjs8G9ydEbq+OXcKWEdwSsBhP/cMvI7ss3dps1f5iNPT5Vv
50E/kUz+aWYy7pKlB18VDV7TUOA3SuYuGknWV8+bOY5uPb8hNT3Y3fHOg/EuNNN3
DIuYH1V7XQkXtF+oNVIGxzzJCXULBE7egMcWAm1ydSOHK0JwkZAiL7OhI7ceVD0x
YlDxBnqmi4cgzfBzTxITAhn3OParwN6udQprdF1WGtFF6fuY2eRDSH/L/iZoE4DY
OulL951OsBtF8YC3+RKLk908/0bA2Uw8ftjCOFJTYbSnZBj1gWK41VkCYMEXiHQk
EaN8+2Iw206iYIoyvdjGCLw7Y0oakDoVD9vmv12SOaHeQljTkjoN8oIlfjjKTeP7
3AXj5v9BDMDVh40nkVayysRNvqe48Kwt9Wn0rhVTLxwdJEiFG/OIU6HLuTkretdN
dcCNFSQrRieSFHpBK9G0vKIpIss1ZwLm8gjocVXH7VK4Mo/TNQe4p2/wAF29mq4r
xu1UiXmtU3uWxiqZnt72LOYFCarQ0sFA5+pMEvF5W+NrVB0wGpXhcwm+pGsIi4IM
LepccTgykiUBqW5TRzPz
=/oS+
-----END PGP SIGNATURE-----
Merge tag 'arm64-upstream' of git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux
Pull arm64 updates from Catalin Marinas:
"Here are the main arm64 updates for 4.6. There are some relatively
intrusive changes to support KASLR, the reworking of the kernel
virtual memory layout and initial page table creation.
Summary:
- Initial page table creation reworked to avoid breaking large block
mappings (huge pages) into smaller ones. The ARM architecture
requires break-before-make in such cases to avoid TLB conflicts but
that's not always possible on live page tables
- Kernel virtual memory layout: the kernel image is no longer linked
to the bottom of the linear mapping (PAGE_OFFSET) but at the bottom
of the vmalloc space, allowing the kernel to be loaded (nearly)
anywhere in physical RAM
- Kernel ASLR: position independent kernel Image and modules being
randomly mapped in the vmalloc space with the randomness is
provided by UEFI (efi_get_random_bytes() patches merged via the
arm64 tree, acked by Matt Fleming)
- Implement relative exception tables for arm64, required by KASLR
(initial code for ARCH_HAS_RELATIVE_EXTABLE added to lib/extable.c
but actual x86 conversion to deferred to 4.7 because of the merge
dependencies)
- Support for the User Access Override feature of ARMv8.2: this
allows uaccess functions (get_user etc.) to be implemented using
LDTR/STTR instructions. Such instructions, when run by the kernel,
perform unprivileged accesses adding an extra level of protection.
The set_fs() macro is used to "upgrade" such instruction to
privileged accesses via the UAO bit
- Half-precision floating point support (part of ARMv8.2)
- Optimisations for CPUs with or without a hardware prefetcher (using
run-time code patching)
- copy_page performance improvement to deal with 128 bytes at a time
- Sanity checks on the CPU capabilities (via CPUID) to prevent
incompatible secondary CPUs from being brought up (e.g. weird
big.LITTLE configurations)
- valid_user_regs() reworked for better sanity check of the
sigcontext information (restored pstate information)
- ACPI parking protocol implementation
- CONFIG_DEBUG_RODATA enabled by default
- VDSO code marked as read-only
- DEBUG_PAGEALLOC support
- ARCH_HAS_UBSAN_SANITIZE_ALL enabled
- Erratum workaround Cavium ThunderX SoC
- set_pte_at() fix for PROT_NONE mappings
- Code clean-ups"
* tag 'arm64-upstream' of git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux: (99 commits)
arm64: kasan: Fix zero shadow mapping overriding kernel image shadow
arm64: kasan: Use actual memory node when populating the kernel image shadow
arm64: Update PTE_RDONLY in set_pte_at() for PROT_NONE permission
arm64: Fix misspellings in comments.
arm64: efi: add missing frame pointer assignment
arm64: make mrs_s prefixing implicit in read_cpuid
arm64: enable CONFIG_DEBUG_RODATA by default
arm64: Rework valid_user_regs
arm64: mm: check at build time that PAGE_OFFSET divides the VA space evenly
arm64: KVM: Move kvm_call_hyp back to its original localtion
arm64: mm: treat memstart_addr as a signed quantity
arm64: mm: list kernel sections in order
arm64: lse: deal with clobbered IP registers after branch via PLT
arm64: mm: dump: Use VA_START directly instead of private LOWEST_ADDR
arm64: kconfig: add submenu for 8.2 architectural features
arm64: kernel: acpi: fix ioremap in ACPI parking protocol cpu_postboot
arm64: Add support for Half precision floating point
arm64: Remove fixmap include fragility
arm64: Add workaround for Cavium erratum 27456
arm64: mm: Mark .rodata as RO
...
2016-03-18 11:03:47 +08:00
|
|
|
err = create_hyp_mappings(kvm_ksym_ref(__hyp_text_start),
|
2016-06-13 22:00:48 +08:00
|
|
|
kvm_ksym_ref(__hyp_text_end), PAGE_HYP_EXEC);
|
2013-01-21 07:28:06 +08:00
|
|
|
if (err) {
|
|
|
|
kvm_err("Cannot map world-switch code\n");
|
2015-01-29 19:59:54 +08:00
|
|
|
goto out_err;
|
2013-01-21 07:28:06 +08:00
|
|
|
}
|
|
|
|
|
2021-01-06 02:05:35 +08:00
|
|
|
err = create_hyp_mappings(kvm_ksym_ref(__hyp_rodata_start),
|
|
|
|
kvm_ksym_ref(__hyp_rodata_end), PAGE_HYP_RO);
|
2020-12-03 02:41:08 +08:00
|
|
|
if (err) {
|
2021-01-06 02:05:35 +08:00
|
|
|
kvm_err("Cannot map .hyp.rodata section\n");
|
2020-12-03 02:41:08 +08:00
|
|
|
goto out_err;
|
|
|
|
}
|
|
|
|
|
2016-02-16 20:52:39 +08:00
|
|
|
err = create_hyp_mappings(kvm_ksym_ref(__start_rodata),
|
2016-06-13 22:00:47 +08:00
|
|
|
kvm_ksym_ref(__end_rodata), PAGE_HYP_RO);
|
2015-10-27 20:18:48 +08:00
|
|
|
if (err) {
|
|
|
|
kvm_err("Cannot map rodata section\n");
|
2016-10-20 17:17:21 +08:00
|
|
|
goto out_err;
|
|
|
|
}
|
|
|
|
|
2021-03-19 18:01:15 +08:00
|
|
|
/*
|
|
|
|
* .hyp.bss is guaranteed to be placed at the beginning of the .bss
|
|
|
|
* section thanks to an assertion in the linker script. Map it RW and
|
|
|
|
* the rest of .bss RO.
|
|
|
|
*/
|
|
|
|
err = create_hyp_mappings(kvm_ksym_ref(__hyp_bss_start),
|
|
|
|
kvm_ksym_ref(__hyp_bss_end), PAGE_HYP);
|
|
|
|
if (err) {
|
|
|
|
kvm_err("Cannot map hyp bss section: %d\n", err);
|
|
|
|
goto out_err;
|
|
|
|
}
|
|
|
|
|
|
|
|
err = create_hyp_mappings(kvm_ksym_ref(__hyp_bss_end),
|
2016-10-20 17:17:21 +08:00
|
|
|
kvm_ksym_ref(__bss_stop), PAGE_HYP_RO);
|
|
|
|
if (err) {
|
|
|
|
kvm_err("Cannot map bss section\n");
|
2015-01-29 19:59:54 +08:00
|
|
|
goto out_err;
|
2015-10-27 20:18:48 +08:00
|
|
|
}
|
|
|
|
|
2013-01-21 07:28:06 +08:00
|
|
|
/*
|
|
|
|
* Map the Hyp stack pages
|
|
|
|
*/
|
|
|
|
for_each_possible_cpu(cpu) {
|
2022-04-21 05:42:54 +08:00
|
|
|
struct kvm_nvhe_init_params *params = per_cpu_ptr_nvhe_sym(kvm_init_params, cpu);
|
2013-01-21 07:28:06 +08:00
|
|
|
char *stack_page = (char *)per_cpu(kvm_arm_hyp_stack_page, cpu);
|
2022-04-21 05:42:54 +08:00
|
|
|
unsigned long hyp_addr;
|
2013-01-21 07:28:06 +08:00
|
|
|
|
2022-04-21 05:42:54 +08:00
|
|
|
/*
|
|
|
|
* Allocate a contiguous HYP private VA range for the stack
|
|
|
|
* and guard page. The allocation is also aligned based on
|
|
|
|
* the order of its size.
|
|
|
|
*/
|
|
|
|
err = hyp_alloc_private_va_range(PAGE_SIZE * 2, &hyp_addr);
|
|
|
|
if (err) {
|
|
|
|
kvm_err("Cannot allocate hyp stack guard page\n");
|
|
|
|
goto out_err;
|
|
|
|
}
|
2013-01-21 07:28:06 +08:00
|
|
|
|
2022-04-21 05:42:54 +08:00
|
|
|
/*
|
|
|
|
* Since the stack grows downwards, map the stack to the page
|
|
|
|
* at the higher address and leave the lower guard page
|
|
|
|
* unbacked.
|
|
|
|
*
|
|
|
|
* Any valid stack address now has the PAGE_SHIFT bit as 1
|
|
|
|
* and addresses corresponding to the guard page have the
|
|
|
|
* PAGE_SHIFT bit as 0 - this is used for overflow detection.
|
|
|
|
*/
|
|
|
|
err = __create_hyp_mappings(hyp_addr + PAGE_SIZE, PAGE_SIZE,
|
|
|
|
__pa(stack_page), PAGE_HYP);
|
2013-01-21 07:28:06 +08:00
|
|
|
if (err) {
|
|
|
|
kvm_err("Cannot map hyp stack\n");
|
2015-01-29 19:59:54 +08:00
|
|
|
goto out_err;
|
2013-01-21 07:28:06 +08:00
|
|
|
}
|
2022-04-21 05:42:54 +08:00
|
|
|
|
|
|
|
/*
|
|
|
|
* Save the stack PA in nvhe_init_params. This will be needed
|
|
|
|
* to recreate the stack mapping in protected nVHE mode.
|
|
|
|
* __hyp_pa() won't do the right thing there, since the stack
|
|
|
|
* has been mapped in the flexible private VA space.
|
|
|
|
*/
|
|
|
|
params->stack_pa = __pa(stack_page);
|
|
|
|
|
|
|
|
params->stack_hyp_va = hyp_addr + (2 * PAGE_SIZE);
|
2013-01-21 07:28:06 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
for_each_possible_cpu(cpu) {
|
2020-09-23 04:49:09 +08:00
|
|
|
char *percpu_begin = (char *)kvm_arm_hyp_percpu_base[cpu];
|
|
|
|
char *percpu_end = percpu_begin + nvhe_percpu_size();
|
2013-01-21 07:28:06 +08:00
|
|
|
|
2021-03-19 18:01:12 +08:00
|
|
|
/* Map Hyp percpu pages */
|
2020-09-23 04:49:09 +08:00
|
|
|
err = create_hyp_mappings(percpu_begin, percpu_end, PAGE_HYP);
|
2013-01-21 07:28:06 +08:00
|
|
|
if (err) {
|
2020-09-23 04:49:09 +08:00
|
|
|
kvm_err("Cannot map hyp percpu region\n");
|
2020-09-15 18:46:30 +08:00
|
|
|
goto out_err;
|
|
|
|
}
|
2021-03-19 18:01:12 +08:00
|
|
|
|
|
|
|
/* Prepare the CPU initialization parameters */
|
|
|
|
cpu_prepare_hyp_mode(cpu);
|
2013-01-21 07:28:06 +08:00
|
|
|
}
|
|
|
|
|
2020-12-03 02:41:12 +08:00
|
|
|
if (is_protected_kvm_enabled()) {
|
2020-12-03 02:41:10 +08:00
|
|
|
init_cpu_logical_map();
|
|
|
|
|
2021-04-06 20:17:59 +08:00
|
|
|
if (!init_psci_relay()) {
|
|
|
|
err = -ENODEV;
|
2020-12-03 02:41:12 +08:00
|
|
|
goto out_err;
|
2021-04-06 20:17:59 +08:00
|
|
|
}
|
2020-12-03 02:41:12 +08:00
|
|
|
}
|
|
|
|
|
2021-03-19 18:01:26 +08:00
|
|
|
if (is_protected_kvm_enabled()) {
|
|
|
|
err = kvm_hyp_init_protection(hyp_va_bits);
|
|
|
|
if (err) {
|
|
|
|
kvm_err("Failed to init hyp memory protection\n");
|
2020-12-03 02:41:12 +08:00
|
|
|
goto out_err;
|
2021-03-19 18:01:26 +08:00
|
|
|
}
|
2020-12-03 02:41:12 +08:00
|
|
|
}
|
|
|
|
|
2013-01-21 07:28:06 +08:00
|
|
|
return 0;
|
2015-01-29 19:59:54 +08:00
|
|
|
|
2013-01-21 07:28:06 +08:00
|
|
|
out_err:
|
2015-01-29 19:59:54 +08:00
|
|
|
teardown_hyp_mode();
|
2013-01-21 07:28:06 +08:00
|
|
|
kvm_err("error initializing Hyp mode: %d\n", err);
|
|
|
|
return err;
|
|
|
|
}
|
|
|
|
|
2021-10-08 21:58:37 +08:00
|
|
|
static void _kvm_host_prot_finalize(void *arg)
|
2021-03-19 18:01:43 +08:00
|
|
|
{
|
2021-10-08 21:58:37 +08:00
|
|
|
int *err = arg;
|
|
|
|
|
|
|
|
if (WARN_ON(kvm_call_hyp_nvhe(__pkvm_prot_finalize)))
|
|
|
|
WRITE_ONCE(*err, -EINVAL);
|
|
|
|
}
|
|
|
|
|
|
|
|
static int pkvm_drop_host_privileges(void)
|
|
|
|
{
|
|
|
|
int ret = 0;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Flip the static key upfront as that may no longer be possible
|
|
|
|
* once the host stage 2 is installed.
|
|
|
|
*/
|
|
|
|
static_branch_enable(&kvm_protected_mode_initialized);
|
|
|
|
on_each_cpu(_kvm_host_prot_finalize, &ret, 1);
|
|
|
|
return ret;
|
2021-03-19 18:01:43 +08:00
|
|
|
}
|
|
|
|
|
2021-03-19 18:01:26 +08:00
|
|
|
static int finalize_hyp_mode(void)
|
|
|
|
{
|
|
|
|
if (!is_protected_kvm_enabled())
|
|
|
|
return 0;
|
|
|
|
|
2021-08-02 20:38:30 +08:00
|
|
|
/*
|
|
|
|
* Exclude HYP BSS from kmemleak so that it doesn't get peeked
|
|
|
|
* at, which would end badly once the section is inaccessible.
|
|
|
|
* None of other sections should ever be introspected.
|
|
|
|
*/
|
|
|
|
kmemleak_free_part(__hyp_bss_start, __hyp_bss_end - __hyp_bss_start);
|
2021-10-08 21:58:37 +08:00
|
|
|
return pkvm_drop_host_privileges();
|
2021-03-19 18:01:26 +08:00
|
|
|
}
|
|
|
|
|
2014-06-02 21:37:13 +08:00
|
|
|
struct kvm_vcpu *kvm_mpidr_to_vcpu(struct kvm *kvm, unsigned long mpidr)
|
|
|
|
{
|
|
|
|
struct kvm_vcpu *vcpu;
|
2021-11-17 00:04:02 +08:00
|
|
|
unsigned long i;
|
2014-06-02 21:37:13 +08:00
|
|
|
|
|
|
|
mpidr &= MPIDR_HWID_BITMASK;
|
|
|
|
kvm_for_each_vcpu(i, vcpu, kvm) {
|
|
|
|
if (mpidr == kvm_vcpu_get_mpidr_aff(vcpu))
|
|
|
|
return vcpu;
|
|
|
|
}
|
|
|
|
return NULL;
|
|
|
|
}
|
|
|
|
|
2017-10-27 22:28:31 +08:00
|
|
|
bool kvm_arch_has_irq_bypass(void)
|
|
|
|
{
|
|
|
|
return true;
|
|
|
|
}
|
|
|
|
|
|
|
|
int kvm_arch_irq_bypass_add_producer(struct irq_bypass_consumer *cons,
|
|
|
|
struct irq_bypass_producer *prod)
|
|
|
|
{
|
|
|
|
struct kvm_kernel_irqfd *irqfd =
|
|
|
|
container_of(cons, struct kvm_kernel_irqfd, consumer);
|
|
|
|
|
2017-10-27 22:28:39 +08:00
|
|
|
return kvm_vgic_v4_set_forwarding(irqfd->kvm, prod->irq,
|
|
|
|
&irqfd->irq_entry);
|
2017-10-27 22:28:31 +08:00
|
|
|
}
|
|
|
|
void kvm_arch_irq_bypass_del_producer(struct irq_bypass_consumer *cons,
|
|
|
|
struct irq_bypass_producer *prod)
|
|
|
|
{
|
|
|
|
struct kvm_kernel_irqfd *irqfd =
|
|
|
|
container_of(cons, struct kvm_kernel_irqfd, consumer);
|
|
|
|
|
2017-10-27 22:28:39 +08:00
|
|
|
kvm_vgic_v4_unset_forwarding(irqfd->kvm, prod->irq,
|
|
|
|
&irqfd->irq_entry);
|
2017-10-27 22:28:31 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
void kvm_arch_irq_bypass_stop(struct irq_bypass_consumer *cons)
|
|
|
|
{
|
|
|
|
struct kvm_kernel_irqfd *irqfd =
|
|
|
|
container_of(cons, struct kvm_kernel_irqfd, consumer);
|
|
|
|
|
|
|
|
kvm_arm_halt_guest(irqfd->kvm);
|
|
|
|
}
|
|
|
|
|
|
|
|
void kvm_arch_irq_bypass_start(struct irq_bypass_consumer *cons)
|
|
|
|
{
|
|
|
|
struct kvm_kernel_irqfd *irqfd =
|
|
|
|
container_of(cons, struct kvm_kernel_irqfd, consumer);
|
|
|
|
|
|
|
|
kvm_arm_resume_guest(irqfd->kvm);
|
|
|
|
}
|
|
|
|
|
2013-01-21 07:28:06 +08:00
|
|
|
/**
|
|
|
|
* Initialize Hyp-mode and memory mappings on all CPUs.
|
|
|
|
*/
|
2013-01-21 07:28:06 +08:00
|
|
|
int kvm_arch_init(void *opaque)
|
|
|
|
{
|
2013-01-21 07:28:06 +08:00
|
|
|
int err;
|
2017-10-20 19:34:16 +08:00
|
|
|
bool in_hyp_mode;
|
2013-01-21 07:28:06 +08:00
|
|
|
|
|
|
|
if (!is_hyp_mode_available()) {
|
2017-11-28 23:18:19 +08:00
|
|
|
kvm_info("HYP mode not available\n");
|
2013-01-21 07:28:06 +08:00
|
|
|
return -ENODEV;
|
|
|
|
}
|
|
|
|
|
2021-10-02 01:05:53 +08:00
|
|
|
if (kvm_get_mode() == KVM_MODE_NONE) {
|
|
|
|
kvm_info("KVM disabled from command line\n");
|
|
|
|
return -ENODEV;
|
|
|
|
}
|
|
|
|
|
2022-04-28 18:34:04 +08:00
|
|
|
err = kvm_sys_reg_table_init();
|
|
|
|
if (err) {
|
|
|
|
kvm_info("Error initializing system register tables");
|
|
|
|
return err;
|
|
|
|
}
|
|
|
|
|
2018-12-07 01:31:20 +08:00
|
|
|
in_hyp_mode = is_kernel_in_hyp_mode();
|
|
|
|
|
2020-10-29 02:28:39 +08:00
|
|
|
if (cpus_have_final_cap(ARM64_WORKAROUND_DEVICE_LOAD_ACQUIRE) ||
|
|
|
|
cpus_have_final_cap(ARM64_WORKAROUND_1508412))
|
2020-08-04 03:31:25 +08:00
|
|
|
kvm_info("Guests without required CPU erratum workarounds can deadlock system!\n" \
|
|
|
|
"Only trusted guests should be used on this system.\n");
|
|
|
|
|
2021-08-12 13:09:52 +08:00
|
|
|
err = kvm_set_ipa_limit();
|
2013-01-21 07:28:06 +08:00
|
|
|
if (err)
|
2015-01-29 19:59:54 +08:00
|
|
|
return err;
|
2013-01-21 07:28:06 +08:00
|
|
|
|
2019-04-12 22:30:58 +08:00
|
|
|
err = kvm_arm_init_sve();
|
2019-03-01 02:33:00 +08:00
|
|
|
if (err)
|
|
|
|
return err;
|
|
|
|
|
2021-11-22 20:18:43 +08:00
|
|
|
err = kvm_arm_vmid_alloc_init();
|
|
|
|
if (err) {
|
|
|
|
kvm_err("Failed to initialize VMID allocator.\n");
|
|
|
|
return err;
|
|
|
|
}
|
|
|
|
|
2017-10-20 19:34:16 +08:00
|
|
|
if (!in_hyp_mode) {
|
2015-01-29 19:59:54 +08:00
|
|
|
err = init_hyp_mode();
|
2017-10-20 19:34:16 +08:00
|
|
|
if (err)
|
|
|
|
goto out_err;
|
|
|
|
}
|
arm, kvm: Fix CPU hotplug callback registration
On 03/15/2014 12:40 AM, Christoffer Dall wrote:
> On Fri, Mar 14, 2014 at 11:13:29AM +0530, Srivatsa S. Bhat wrote:
>> On 03/13/2014 04:51 AM, Christoffer Dall wrote:
>>> On Tue, Mar 11, 2014 at 02:05:38AM +0530, Srivatsa S. Bhat wrote:
>>>> Subsystems that want to register CPU hotplug callbacks, as well as perform
>>>> initialization for the CPUs that are already online, often do it as shown
>>>> below:
>>>>
[...]
>>> Just so we're clear, the existing code was simply racy as not prone to
>>> deadlocks, right?
>>>
>>> This makes it clear that the test above for compatible CPUs can be quite
>>> easily evaded by using CPU hotplug, but we don't really have a good
>>> solution for handling that yet... Hmmm, grumble grumble, I guess if you
>>> hotplug unsupported CPUs on a KVM/ARM system for now, stuff will break.
>>>
>>
>> In this particular case, there was no deadlock possibility, rather the
>> existing code had insufficient synchronization against CPU hotplug.
>>
>> init_hyp_mode() would invoke cpu_init_hyp_mode() on currently online CPUs
>> using on_each_cpu(). If a CPU came online after this point and before calling
>> register_cpu_notifier(), that CPU would remain uninitialized because this
>> subsystem would miss the hot-online event. This patch fixes this bug and
>> also uses the new synchronization method (instead of get/put_online_cpus())
>> to ensure that we don't deadlock with CPU hotplug.
>>
>
> Yes, that was my conclusion as well. Thanks for clarifying. (It could
> be noted in the commit message as well if you should feel so inclined).
>
Please find the patch with updated changelog (and your Ack) below.
(No changes in code).
From: Srivatsa S. Bhat <srivatsa.bhat@linux.vnet.ibm.com>
Subject: [PATCH] arm, kvm: Fix CPU hotplug callback registration
Subsystems that want to register CPU hotplug callbacks, as well as perform
initialization for the CPUs that are already online, often do it as shown
below:
get_online_cpus();
for_each_online_cpu(cpu)
init_cpu(cpu);
register_cpu_notifier(&foobar_cpu_notifier);
put_online_cpus();
This is wrong, since it is prone to ABBA deadlocks involving the
cpu_add_remove_lock and the cpu_hotplug.lock (when running concurrently
with CPU hotplug operations).
Instead, the correct and race-free way of performing the callback
registration is:
cpu_notifier_register_begin();
for_each_online_cpu(cpu)
init_cpu(cpu);
/* Note the use of the double underscored version of the API */
__register_cpu_notifier(&foobar_cpu_notifier);
cpu_notifier_register_done();
In the existing arm kvm code, there is no synchronization with CPU hotplug
to avoid missing the hotplug events that might occur after invoking
init_hyp_mode() and before calling register_cpu_notifier(). Fix this bug
and also use the new synchronization method (instead of get/put_online_cpus())
to ensure that we don't deadlock with CPU hotplug.
Cc: Gleb Natapov <gleb@kernel.org>
Cc: Russell King <linux@arm.linux.org.uk>
Cc: Ingo Molnar <mingo@kernel.org>
Acked-by: Paolo Bonzini <pbonzini@redhat.com>
Acked-by: Christoffer Dall <christoffer.dall@linaro.org>
Signed-off-by: Srivatsa S. Bhat <srivatsa.bhat@linux.vnet.ibm.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2014-03-18 18:23:05 +08:00
|
|
|
|
2020-11-13 19:38:44 +08:00
|
|
|
err = kvm_init_vector_slots();
|
|
|
|
if (err) {
|
|
|
|
kvm_err("Cannot initialise vector slots\n");
|
|
|
|
goto out_err;
|
|
|
|
}
|
|
|
|
|
2015-01-29 19:59:54 +08:00
|
|
|
err = init_subsystems();
|
|
|
|
if (err)
|
|
|
|
goto out_hyp;
|
2013-08-05 22:04:46 +08:00
|
|
|
|
2021-03-19 18:01:26 +08:00
|
|
|
if (!in_hyp_mode) {
|
|
|
|
err = finalize_hyp_mode();
|
|
|
|
if (err) {
|
|
|
|
kvm_err("Failed to finalize Hyp protection\n");
|
|
|
|
goto out_hyp;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2020-12-03 02:41:22 +08:00
|
|
|
if (is_protected_kvm_enabled()) {
|
2020-12-03 02:40:58 +08:00
|
|
|
kvm_info("Protected nVHE mode initialized successfully\n");
|
2020-12-03 02:41:22 +08:00
|
|
|
} else if (in_hyp_mode) {
|
2017-10-20 19:34:16 +08:00
|
|
|
kvm_info("VHE mode initialized successfully\n");
|
2020-12-03 02:41:22 +08:00
|
|
|
} else {
|
2017-10-20 19:34:16 +08:00
|
|
|
kvm_info("Hyp mode initialized successfully\n");
|
2020-12-03 02:41:22 +08:00
|
|
|
}
|
2017-10-20 19:34:16 +08:00
|
|
|
|
2013-01-21 07:28:06 +08:00
|
|
|
return 0;
|
2015-01-29 19:59:54 +08:00
|
|
|
|
|
|
|
out_hyp:
|
2019-12-02 15:42:11 +08:00
|
|
|
hyp_cpu_pm_exit();
|
2017-10-20 19:34:16 +08:00
|
|
|
if (!in_hyp_mode)
|
|
|
|
teardown_hyp_mode();
|
2013-01-21 07:28:06 +08:00
|
|
|
out_err:
|
2021-11-22 20:18:43 +08:00
|
|
|
kvm_arm_vmid_alloc_free();
|
2013-01-21 07:28:06 +08:00
|
|
|
return err;
|
2013-01-21 07:28:06 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
/* NOP: Compiling as a module not supported */
|
|
|
|
void kvm_arch_exit(void)
|
|
|
|
{
|
2021-11-11 10:07:37 +08:00
|
|
|
kvm_unregister_perf_callbacks();
|
2013-01-21 07:28:06 +08:00
|
|
|
}
|
|
|
|
|
2020-12-03 02:40:57 +08:00
|
|
|
static int __init early_kvm_mode_cfg(char *arg)
|
|
|
|
{
|
|
|
|
if (!arg)
|
|
|
|
return -EINVAL;
|
|
|
|
|
|
|
|
if (strcmp(arg, "protected") == 0) {
|
|
|
|
kvm_mode = KVM_MODE_PROTECTED;
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2021-10-02 01:05:53 +08:00
|
|
|
if (strcmp(arg, "nvhe") == 0 && !WARN_ON(is_kernel_in_hyp_mode())) {
|
|
|
|
kvm_mode = KVM_MODE_DEFAULT;
|
2021-02-08 17:57:26 +08:00
|
|
|
return 0;
|
2021-10-02 01:05:53 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
if (strcmp(arg, "none") == 0) {
|
|
|
|
kvm_mode = KVM_MODE_NONE;
|
2021-02-08 17:57:26 +08:00
|
|
|
return 0;
|
2021-10-02 01:05:53 +08:00
|
|
|
}
|
2021-02-08 17:57:26 +08:00
|
|
|
|
2020-12-03 02:40:57 +08:00
|
|
|
return -EINVAL;
|
|
|
|
}
|
|
|
|
early_param("kvm-arm.mode", early_kvm_mode_cfg);
|
|
|
|
|
2020-12-03 02:40:58 +08:00
|
|
|
enum kvm_mode kvm_get_mode(void)
|
|
|
|
{
|
|
|
|
return kvm_mode;
|
|
|
|
}
|
|
|
|
|
2013-01-21 07:28:06 +08:00
|
|
|
static int arm_init(void)
|
|
|
|
{
|
|
|
|
int rc = kvm_init(NULL, sizeof(struct kvm_vcpu), 0, THIS_MODULE);
|
|
|
|
return rc;
|
|
|
|
}
|
|
|
|
|
|
|
|
module_init(arm_init);
|