2013-01-21 07:28:06 +08:00
|
|
|
/*
|
|
|
|
* Copyright (C) 2012 - Virtual Open Systems and Columbia University
|
|
|
|
* Author: Christoffer Dall <c.dall@virtualopensystems.com>
|
|
|
|
*
|
|
|
|
* This program is free software; you can redistribute it and/or modify
|
|
|
|
* it under the terms of the GNU General Public License, version 2, as
|
|
|
|
* published by the Free Software Foundation.
|
|
|
|
*
|
|
|
|
* This program is distributed in the hope that it will be useful,
|
|
|
|
* but WITHOUT ANY WARRANTY; without even the implied warranty of
|
|
|
|
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
|
|
|
|
* GNU General Public License for more details.
|
|
|
|
*
|
|
|
|
* You should have received a copy of the GNU General Public License
|
|
|
|
* along with this program; if not, write to the Free Software
|
|
|
|
* Foundation, 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.
|
|
|
|
*/
|
|
|
|
|
2013-04-13 02:12:07 +08:00
|
|
|
#include <linux/cpu.h>
|
2013-08-05 22:04:46 +08:00
|
|
|
#include <linux/cpu_pm.h>
|
2013-01-21 07:28:06 +08:00
|
|
|
#include <linux/errno.h>
|
|
|
|
#include <linux/err.h>
|
|
|
|
#include <linux/kvm_host.h>
|
|
|
|
#include <linux/module.h>
|
|
|
|
#include <linux/vmalloc.h>
|
|
|
|
#include <linux/fs.h>
|
|
|
|
#include <linux/mman.h>
|
|
|
|
#include <linux/sched.h>
|
2013-01-21 07:28:08 +08:00
|
|
|
#include <linux/kvm.h>
|
2013-01-21 07:28:06 +08:00
|
|
|
#include <trace/events/kvm.h>
|
|
|
|
|
|
|
|
#define CREATE_TRACE_POINTS
|
|
|
|
#include "trace.h"
|
|
|
|
|
|
|
|
#include <asm/uaccess.h>
|
|
|
|
#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>
|
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>
|
2013-01-21 07:28:09 +08:00
|
|
|
#include <asm/kvm_coproc.h>
|
2013-01-21 07:28:13 +08:00
|
|
|
#include <asm/kvm_psci.h>
|
2015-10-27 20:18:48 +08:00
|
|
|
#include <asm/sections.h>
|
2013-01-21 07:28:06 +08:00
|
|
|
|
|
|
|
#ifdef REQUIRES_VIRT
|
|
|
|
__asm__(".arch_extension virt");
|
|
|
|
#endif
|
|
|
|
|
2013-01-21 07:28:06 +08:00
|
|
|
static DEFINE_PER_CPU(unsigned long, kvm_arm_hyp_stack_page);
|
2013-04-08 23:47:19 +08:00
|
|
|
static kvm_cpu_context_t __percpu *kvm_host_cpu_state;
|
2013-01-21 07:28:06 +08:00
|
|
|
static unsigned long hyp_default_vectors;
|
|
|
|
|
2013-01-22 08:36:11 +08:00
|
|
|
/* Per-CPU variable containing the currently running vcpu. */
|
|
|
|
static DEFINE_PER_CPU(struct kvm_vcpu *, kvm_arm_running_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
|
|
|
/* The VMID used in the VTTBR */
|
|
|
|
static atomic64_t kvm_vmid_gen = ATOMIC64_INIT(1);
|
2015-11-16 19:28:18 +08:00
|
|
|
static u32 kvm_next_vmid;
|
|
|
|
static unsigned int kvm_vmid_bits __read_mostly;
|
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
|
|
|
static DEFINE_SPINLOCK(kvm_vmid_lock);
|
2013-01-21 07:28:06 +08:00
|
|
|
|
2015-12-18 19:38:43 +08:00
|
|
|
static bool vgic_present;
|
|
|
|
|
2013-01-22 08:36:11 +08:00
|
|
|
static void kvm_arm_set_running_vcpu(struct kvm_vcpu *vcpu)
|
|
|
|
{
|
|
|
|
BUG_ON(preemptible());
|
2013-10-21 20:17:08 +08:00
|
|
|
__this_cpu_write(kvm_arm_running_vcpu, vcpu);
|
2013-01-22 08:36:11 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
|
|
|
* kvm_arm_get_running_vcpu - get the vcpu running on the current CPU.
|
|
|
|
* Must be called from non-preemptible context
|
|
|
|
*/
|
|
|
|
struct kvm_vcpu *kvm_arm_get_running_vcpu(void)
|
|
|
|
{
|
|
|
|
BUG_ON(preemptible());
|
2013-10-21 20:17:08 +08:00
|
|
|
return __this_cpu_read(kvm_arm_running_vcpu);
|
2013-01-22 08:36:11 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
|
|
|
* kvm_arm_get_running_vcpus - get the per-CPU array of currently running vcpus.
|
|
|
|
*/
|
2014-08-26 22:13:21 +08:00
|
|
|
struct kvm_vcpu * __percpu *kvm_get_running_vcpus(void)
|
2013-01-22 08:36:11 +08:00
|
|
|
{
|
|
|
|
return &kvm_arm_running_vcpu;
|
|
|
|
}
|
|
|
|
|
2014-08-28 21:13:03 +08:00
|
|
|
int kvm_arch_hardware_enable(void)
|
2013-01-21 07:28:06 +08:00
|
|
|
{
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
int kvm_arch_vcpu_should_kick(struct kvm_vcpu *vcpu)
|
|
|
|
{
|
|
|
|
return kvm_vcpu_exiting_guest_mode(vcpu) == IN_GUEST_MODE;
|
|
|
|
}
|
|
|
|
|
|
|
|
int kvm_arch_hardware_setup(void)
|
|
|
|
{
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
void kvm_arch_check_processor_compat(void *rtn)
|
|
|
|
{
|
|
|
|
*(int *)rtn = 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
|
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)
|
|
|
|
{
|
2013-01-21 07:28:07 +08:00
|
|
|
int ret = 0;
|
|
|
|
|
2013-01-21 07:28:06 +08:00
|
|
|
if (type)
|
|
|
|
return -EINVAL;
|
|
|
|
|
2013-01-21 07:28:07 +08:00
|
|
|
ret = kvm_alloc_stage2_pgd(kvm);
|
|
|
|
if (ret)
|
|
|
|
goto out_fail_alloc;
|
|
|
|
|
|
|
|
ret = create_hyp_mappings(kvm, kvm + 1);
|
|
|
|
if (ret)
|
|
|
|
goto out_free_stage2_pgd;
|
|
|
|
|
2014-06-24 00:37:18 +08:00
|
|
|
kvm_vgic_early_init(kvm);
|
2013-11-17 02:51:25 +08:00
|
|
|
kvm_timer_init(kvm);
|
|
|
|
|
2013-01-21 07:28:07 +08:00
|
|
|
/* Mark the initial VMID generation invalid */
|
|
|
|
kvm->arch.vmid_gen = 0;
|
|
|
|
|
2014-06-02 22:26:01 +08:00
|
|
|
/* The maximum number of VCPUs is limited by the host's GIC model */
|
2015-12-18 19:38:43 +08:00
|
|
|
kvm->arch.max_vcpus = vgic_present ?
|
|
|
|
kvm_vgic_get_max_vcpus() : KVM_MAX_VCPUS;
|
2014-06-02 22:26:01 +08:00
|
|
|
|
2013-01-21 07:28:07 +08:00
|
|
|
return ret;
|
|
|
|
out_free_stage2_pgd:
|
|
|
|
kvm_free_stage2_pgd(kvm);
|
|
|
|
out_fail_alloc:
|
|
|
|
return ret;
|
2013-01-21 07:28:06 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
int kvm_arch_vcpu_fault(struct kvm_vcpu *vcpu, struct vm_fault *vmf)
|
|
|
|
{
|
|
|
|
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)
|
|
|
|
{
|
|
|
|
int i;
|
|
|
|
|
2013-01-21 07:28:07 +08:00
|
|
|
kvm_free_stage2_pgd(kvm);
|
|
|
|
|
2013-01-21 07:28:06 +08:00
|
|
|
for (i = 0; i < KVM_MAX_VCPUS; ++i) {
|
|
|
|
if (kvm->vcpus[i]) {
|
|
|
|
kvm_arch_vcpu_free(kvm->vcpus[i]);
|
|
|
|
kvm->vcpus[i] = NULL;
|
|
|
|
}
|
|
|
|
}
|
2014-07-08 19:09:01 +08:00
|
|
|
|
|
|
|
kvm_vgic_destroy(kvm);
|
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:
|
2013-01-21 07:28:06 +08:00
|
|
|
r = 1;
|
|
|
|
break;
|
|
|
|
case KVM_CAP_COALESCED_MMIO:
|
|
|
|
r = KVM_COALESCED_MMIO_PAGE_OFFSET;
|
|
|
|
break;
|
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:
|
|
|
|
r = num_online_cpus();
|
|
|
|
break;
|
|
|
|
case KVM_CAP_MAX_VCPUS:
|
|
|
|
r = KVM_MAX_VCPUS;
|
|
|
|
break;
|
|
|
|
default:
|
2013-04-08 23:47:18 +08:00
|
|
|
r = kvm_arch_dev_ioctl_check_extension(ext);
|
2013-01-21 07:28:06 +08:00
|
|
|
break;
|
|
|
|
}
|
|
|
|
return r;
|
|
|
|
}
|
|
|
|
|
|
|
|
long kvm_arch_dev_ioctl(struct file *filp,
|
|
|
|
unsigned int ioctl, unsigned long arg)
|
|
|
|
{
|
|
|
|
return -EINVAL;
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
struct kvm_vcpu *kvm_arch_vcpu_create(struct kvm *kvm, unsigned int id)
|
|
|
|
{
|
|
|
|
int err;
|
|
|
|
struct kvm_vcpu *vcpu;
|
|
|
|
|
2014-12-09 21:33:45 +08:00
|
|
|
if (irqchip_in_kernel(kvm) && vgic_initialized(kvm)) {
|
|
|
|
err = -EBUSY;
|
|
|
|
goto out;
|
|
|
|
}
|
|
|
|
|
2014-06-02 22:26:01 +08:00
|
|
|
if (id >= kvm->arch.max_vcpus) {
|
|
|
|
err = -EINVAL;
|
|
|
|
goto out;
|
|
|
|
}
|
|
|
|
|
2013-01-21 07:28:06 +08:00
|
|
|
vcpu = kmem_cache_zalloc(kvm_vcpu_cache, GFP_KERNEL);
|
|
|
|
if (!vcpu) {
|
|
|
|
err = -ENOMEM;
|
|
|
|
goto out;
|
|
|
|
}
|
|
|
|
|
|
|
|
err = kvm_vcpu_init(vcpu, kvm, id);
|
|
|
|
if (err)
|
|
|
|
goto free_vcpu;
|
|
|
|
|
2013-01-21 07:28:07 +08:00
|
|
|
err = create_hyp_mappings(vcpu, vcpu + 1);
|
|
|
|
if (err)
|
|
|
|
goto vcpu_uninit;
|
|
|
|
|
2013-01-21 07:28:06 +08:00
|
|
|
return vcpu;
|
2013-01-21 07:28:07 +08:00
|
|
|
vcpu_uninit:
|
|
|
|
kvm_vcpu_uninit(vcpu);
|
2013-01-21 07:28:06 +08:00
|
|
|
free_vcpu:
|
|
|
|
kmem_cache_free(kvm_vcpu_cache, vcpu);
|
|
|
|
out:
|
|
|
|
return ERR_PTR(err);
|
|
|
|
}
|
|
|
|
|
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
|
|
|
{
|
2014-06-24 00:37:18 +08:00
|
|
|
kvm_vgic_vcpu_early_init(vcpu);
|
2013-01-21 07:28:06 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
void kvm_arch_vcpu_free(struct kvm_vcpu *vcpu)
|
|
|
|
{
|
2013-01-21 07:28:07 +08:00
|
|
|
kvm_mmu_free_memory_caches(vcpu);
|
2013-01-24 02:21:59 +08:00
|
|
|
kvm_timer_vcpu_terminate(vcpu);
|
2014-07-08 19:09:01 +08:00
|
|
|
kvm_vgic_vcpu_destroy(vcpu);
|
2013-01-21 07:28:07 +08:00
|
|
|
kmem_cache_free(kvm_vcpu_cache, vcpu);
|
2013-01-21 07:28:06 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
void kvm_arch_vcpu_destroy(struct kvm_vcpu *vcpu)
|
|
|
|
{
|
|
|
|
kvm_arch_vcpu_free(vcpu);
|
|
|
|
}
|
|
|
|
|
|
|
|
int kvm_cpu_has_pending_timer(struct kvm_vcpu *vcpu)
|
|
|
|
{
|
arm/arm64: KVM: Fix migration race in the arch timer
When a VCPU is no longer running, we currently check to see if it has a
timer scheduled in the future, and if it does, we schedule a host
hrtimer to notify is in case the timer expires while the VCPU is still
not running. When the hrtimer fires, we mask the guest's timer and
inject the timer IRQ (still relying on the guest unmasking the time when
it receives the IRQ).
This is all good and fine, but when migration a VM (checkpoint/restore)
this introduces a race. It is unlikely, but possible, for the following
sequence of events to happen:
1. Userspace stops the VM
2. Hrtimer for VCPU is scheduled
3. Userspace checkpoints the VGIC state (no pending timer interrupts)
4. The hrtimer fires, schedules work in a workqueue
5. Workqueue function runs, masks the timer and injects timer interrupt
6. Userspace checkpoints the timer state (timer masked)
At restore time, you end up with a masked timer without any timer
interrupts and your guest halts never receiving timer interrupts.
Fix this by only kicking the VCPU in the workqueue function, and sample
the expired state of the timer when entering the guest again and inject
the interrupt and mask the timer only then.
Signed-off-by: Christoffer Dall <christoffer.dall@linaro.org>
Signed-off-by: Alex Bennée <alex.bennee@linaro.org>
Signed-off-by: Christoffer Dall <christoffer.dall@linaro.org>
2015-03-14 01:02:55 +08:00
|
|
|
return kvm_timer_should_fire(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_timer_schedule(vcpu);
|
|
|
|
}
|
|
|
|
|
|
|
|
void kvm_arch_vcpu_unblocking(struct kvm_vcpu *vcpu)
|
|
|
|
{
|
|
|
|
kvm_timer_unschedule(vcpu);
|
|
|
|
}
|
|
|
|
|
2013-01-21 07:28:06 +08:00
|
|
|
int kvm_arch_vcpu_init(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
|
|
|
/* Force users to call KVM_ARM_VCPU_INIT */
|
|
|
|
vcpu->arch.target = -1;
|
2014-10-16 22:40:53 +08:00
|
|
|
bitmap_zero(vcpu->arch.features, KVM_VCPU_MAX_FEATURES);
|
2013-01-22 08:36:12 +08:00
|
|
|
|
2013-01-24 02:21:59 +08:00
|
|
|
/* Set up the timer */
|
|
|
|
kvm_timer_vcpu_init(vcpu);
|
|
|
|
|
2015-07-08 00:30:00 +08:00
|
|
|
kvm_arm_reset_debug_ptr(vcpu);
|
|
|
|
|
2013-01-21 07:28:06 +08:00
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
void kvm_arch_vcpu_load(struct kvm_vcpu *vcpu, int cpu)
|
|
|
|
{
|
2013-01-21 07:28:08 +08:00
|
|
|
vcpu->cpu = cpu;
|
2013-04-08 23:47:19 +08:00
|
|
|
vcpu->arch.host_cpu_context = this_cpu_ptr(kvm_host_cpu_state);
|
2013-01-21 07:28:09 +08:00
|
|
|
|
2013-01-22 08:36:11 +08:00
|
|
|
kvm_arm_set_running_vcpu(vcpu);
|
2013-01-21 07:28:06 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
void kvm_arch_vcpu_put(struct kvm_vcpu *vcpu)
|
|
|
|
{
|
2013-12-12 12:29:11 +08:00
|
|
|
/*
|
|
|
|
* The arch-generic KVM code expects the cpu field of a vcpu to be -1
|
|
|
|
* if the vcpu is no longer assigned to a cpu. This is used for the
|
|
|
|
* optimized make_all_cpus_request path.
|
|
|
|
*/
|
|
|
|
vcpu->cpu = -1;
|
|
|
|
|
2013-01-22 08:36:11 +08:00
|
|
|
kvm_arm_set_running_vcpu(NULL);
|
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)
|
|
|
|
{
|
2015-09-26 05:41:14 +08:00
|
|
|
if (vcpu->arch.power_off)
|
2015-03-14 01:02:52 +08:00
|
|
|
mp_state->mp_state = KVM_MP_STATE_STOPPED;
|
|
|
|
else
|
|
|
|
mp_state->mp_state = KVM_MP_STATE_RUNNABLE;
|
|
|
|
|
|
|
|
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)
|
|
|
|
{
|
2015-03-14 01:02:52 +08:00
|
|
|
switch (mp_state->mp_state) {
|
|
|
|
case KVM_MP_STATE_RUNNABLE:
|
2015-09-26 05:41:14 +08:00
|
|
|
vcpu->arch.power_off = false;
|
2015-03-14 01:02:52 +08:00
|
|
|
break;
|
|
|
|
case KVM_MP_STATE_STOPPED:
|
2015-09-26 05:41:14 +08:00
|
|
|
vcpu->arch.power_off = true;
|
2015-03-14 01:02:52 +08:00
|
|
|
break;
|
|
|
|
default:
|
|
|
|
return -EINVAL;
|
|
|
|
}
|
|
|
|
|
|
|
|
return 0;
|
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)
|
|
|
|
{
|
2015-09-26 05:41:15 +08:00
|
|
|
return ((!!v->arch.irq_lines || kvm_vgic_vcpu_pending_irq(v))
|
2015-09-26 05:41:17 +08:00
|
|
|
&& !v->arch.power_off && !v->arch.pause);
|
2013-01-21 07:28:06 +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
|
|
|
/* Just ensure a guest exit from a particular CPU */
|
|
|
|
static void exit_vm_noop(void *info)
|
|
|
|
{
|
|
|
|
}
|
|
|
|
|
|
|
|
void force_vm_exit(const cpumask_t *mask)
|
|
|
|
{
|
|
|
|
smp_call_function_many(mask, exit_vm_noop, NULL, true);
|
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
|
|
|
* need_new_vmid_gen - check that the VMID is still valid
|
|
|
|
* @kvm: The VM's VMID to checkt
|
|
|
|
*
|
|
|
|
* return true if there is a new generation of VMIDs being used
|
|
|
|
*
|
|
|
|
* The hardware supports only 256 values with the value zero reserved for the
|
|
|
|
* host, so we check if an assigned value belongs to a previous generation,
|
|
|
|
* which which requires us to assign a new value. If we're the first to use a
|
|
|
|
* VMID for the new generation, we must flush necessary caches and TLBs on all
|
|
|
|
* CPUs.
|
|
|
|
*/
|
|
|
|
static bool need_new_vmid_gen(struct kvm *kvm)
|
|
|
|
{
|
|
|
|
return unlikely(kvm->arch.vmid_gen != atomic64_read(&kvm_vmid_gen));
|
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
|
|
|
* update_vttbr - Update the VTTBR with a valid VMID before the guest runs
|
|
|
|
* @kvm The guest that we are about to run
|
|
|
|
*
|
|
|
|
* Called from kvm_arch_vcpu_ioctl_run before entering the guest to ensure the
|
|
|
|
* VM has a valid VMID, otherwise assigns a new one and flushes corresponding
|
|
|
|
* caches and TLBs.
|
|
|
|
*/
|
|
|
|
static void update_vttbr(struct kvm *kvm)
|
|
|
|
{
|
|
|
|
phys_addr_t pgd_phys;
|
|
|
|
u64 vmid;
|
|
|
|
|
|
|
|
if (!need_new_vmid_gen(kvm))
|
|
|
|
return;
|
|
|
|
|
|
|
|
spin_lock(&kvm_vmid_lock);
|
|
|
|
|
|
|
|
/*
|
|
|
|
* We need to re-check the vmid_gen here to ensure that if another vcpu
|
|
|
|
* already allocated a valid vmid for this vm, then this vcpu should
|
|
|
|
* use the same vmid.
|
|
|
|
*/
|
|
|
|
if (!need_new_vmid_gen(kvm)) {
|
|
|
|
spin_unlock(&kvm_vmid_lock);
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* First user of a new VMID generation? */
|
|
|
|
if (unlikely(kvm_next_vmid == 0)) {
|
|
|
|
atomic64_inc(&kvm_vmid_gen);
|
|
|
|
kvm_next_vmid = 1;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* On SMP we know no other CPUs can use this CPU's or each
|
|
|
|
* other's VMID after force_vm_exit returns since the
|
|
|
|
* kvm_vmid_lock blocks them from reentry to the guest.
|
|
|
|
*/
|
|
|
|
force_vm_exit(cpu_all_mask);
|
|
|
|
/*
|
|
|
|
* Now broadcast TLB + ICACHE invalidation over the inner
|
|
|
|
* shareable domain to make sure all data structures are
|
|
|
|
* clean.
|
|
|
|
*/
|
|
|
|
kvm_call_hyp(__kvm_flush_vm_context);
|
|
|
|
}
|
|
|
|
|
|
|
|
kvm->arch.vmid_gen = atomic64_read(&kvm_vmid_gen);
|
|
|
|
kvm->arch.vmid = kvm_next_vmid;
|
|
|
|
kvm_next_vmid++;
|
2015-11-16 19:28:18 +08:00
|
|
|
kvm_next_vmid &= (1 << kvm_vmid_bits) - 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
|
|
|
|
|
|
|
/* update vttbr to be used with the new vmid */
|
2014-10-10 18:14:28 +08:00
|
|
|
pgd_phys = virt_to_phys(kvm_get_hwpgd(kvm));
|
2014-07-10 00:17:04 +08:00
|
|
|
BUG_ON(pgd_phys & ~VTTBR_BADDR_MASK);
|
2015-11-16 19:28:18 +08:00
|
|
|
vmid = ((u64)(kvm->arch.vmid) << VTTBR_VMID_SHIFT) & VTTBR_VMID_MASK(kvm_vmid_bits);
|
2014-07-10 00:17:04 +08:00
|
|
|
kvm->arch.vttbr = pgd_phys | vmid;
|
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
|
|
|
|
|
|
|
spin_unlock(&kvm_vmid_lock);
|
|
|
|
}
|
|
|
|
|
|
|
|
static int kvm_vcpu_first_run_init(struct kvm_vcpu *vcpu)
|
|
|
|
{
|
2014-12-13 04:19:23 +08:00
|
|
|
struct kvm *kvm = vcpu->kvm;
|
2013-09-24 05:55:55 +08:00
|
|
|
int 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
|
|
|
if (likely(vcpu->arch.has_run_once))
|
|
|
|
return 0;
|
|
|
|
|
|
|
|
vcpu->arch.has_run_once = true;
|
2013-01-21 07:28:13 +08:00
|
|
|
|
2013-01-22 08:36:16 +08:00
|
|
|
/*
|
2014-12-04 23:02:24 +08:00
|
|
|
* Map the VGIC hardware resources before running a vcpu the first
|
|
|
|
* time on this VM.
|
2013-01-22 08:36:16 +08:00
|
|
|
*/
|
2015-08-05 18:53:57 +08:00
|
|
|
if (unlikely(irqchip_in_kernel(kvm) && !vgic_ready(kvm))) {
|
2014-12-13 04:19:23 +08:00
|
|
|
ret = kvm_vgic_map_resources(kvm);
|
2013-01-22 08:36:16 +08:00
|
|
|
if (ret)
|
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
|
2014-12-13 04:19:23 +08:00
|
|
|
/*
|
|
|
|
* Enable the arch timers only if we have an in-kernel VGIC
|
|
|
|
* and it has been properly initialized, since we cannot handle
|
|
|
|
* interrupts from the virtual timer with a userspace gic.
|
|
|
|
*/
|
|
|
|
if (irqchip_in_kernel(kvm) && vgic_initialized(kvm))
|
|
|
|
kvm_timer_enable(kvm);
|
|
|
|
|
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 0;
|
|
|
|
}
|
|
|
|
|
2015-03-04 18:14:34 +08:00
|
|
|
bool kvm_arch_intc_initialized(struct kvm *kvm)
|
|
|
|
{
|
|
|
|
return vgic_initialized(kvm);
|
|
|
|
}
|
|
|
|
|
2015-09-26 05:41:17 +08:00
|
|
|
static void kvm_arm_halt_guest(struct kvm *kvm) __maybe_unused;
|
|
|
|
static void kvm_arm_resume_guest(struct kvm *kvm) __maybe_unused;
|
|
|
|
|
|
|
|
static void kvm_arm_halt_guest(struct kvm *kvm)
|
|
|
|
{
|
|
|
|
int i;
|
|
|
|
struct kvm_vcpu *vcpu;
|
|
|
|
|
|
|
|
kvm_for_each_vcpu(i, vcpu, kvm)
|
|
|
|
vcpu->arch.pause = true;
|
|
|
|
force_vm_exit(cpu_all_mask);
|
|
|
|
}
|
|
|
|
|
|
|
|
static void kvm_arm_resume_guest(struct kvm *kvm)
|
|
|
|
{
|
|
|
|
int i;
|
|
|
|
struct kvm_vcpu *vcpu;
|
|
|
|
|
|
|
|
kvm_for_each_vcpu(i, vcpu, kvm) {
|
|
|
|
wait_queue_head_t *wq = kvm_arch_vcpu_wq(vcpu);
|
|
|
|
|
|
|
|
vcpu->arch.pause = false;
|
|
|
|
wake_up_interruptible(wq);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2015-09-26 05:41:14 +08:00
|
|
|
static void vcpu_sleep(struct kvm_vcpu *vcpu)
|
2013-01-21 07:28:13 +08:00
|
|
|
{
|
|
|
|
wait_queue_head_t *wq = kvm_arch_vcpu_wq(vcpu);
|
|
|
|
|
2015-09-26 05:41:17 +08:00
|
|
|
wait_event_interruptible(*wq, ((!vcpu->arch.power_off) &&
|
|
|
|
(!vcpu->arch.pause)));
|
2013-01-21 07:28:13 +08:00
|
|
|
}
|
|
|
|
|
2013-05-09 06:28:06 +08:00
|
|
|
static int kvm_vcpu_initialized(struct kvm_vcpu *vcpu)
|
|
|
|
{
|
|
|
|
return vcpu->arch.target >= 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
|
|
|
/**
|
|
|
|
* kvm_arch_vcpu_ioctl_run - the main VCPU run function to execute guest code
|
|
|
|
* @vcpu: The VCPU pointer
|
|
|
|
* @run: The kvm_run structure pointer used for userspace state exchange
|
|
|
|
*
|
|
|
|
* 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.
|
|
|
|
*/
|
2013-01-21 07:28:06 +08:00
|
|
|
int kvm_arch_vcpu_ioctl_run(struct kvm_vcpu *vcpu, struct kvm_run *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;
|
|
|
|
sigset_t sigsaved;
|
|
|
|
|
2013-05-09 06:28:06 +08:00
|
|
|
if (unlikely(!kvm_vcpu_initialized(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 -ENOEXEC;
|
|
|
|
|
|
|
|
ret = kvm_vcpu_first_run_init(vcpu);
|
|
|
|
if (ret)
|
|
|
|
return ret;
|
|
|
|
|
2013-01-21 07:43:58 +08:00
|
|
|
if (run->exit_reason == KVM_EXIT_MMIO) {
|
|
|
|
ret = kvm_handle_mmio_return(vcpu, vcpu->run);
|
|
|
|
if (ret)
|
|
|
|
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
|
|
|
if (vcpu->sigset_active)
|
|
|
|
sigprocmask(SIG_SETMASK, &vcpu->sigset, &sigsaved);
|
|
|
|
|
|
|
|
ret = 1;
|
|
|
|
run->exit_reason = KVM_EXIT_UNKNOWN;
|
|
|
|
while (ret > 0) {
|
|
|
|
/*
|
|
|
|
* Check conditions before entering the guest
|
|
|
|
*/
|
|
|
|
cond_resched();
|
|
|
|
|
|
|
|
update_vttbr(vcpu->kvm);
|
|
|
|
|
2015-09-26 05:41:17 +08:00
|
|
|
if (vcpu->arch.power_off || vcpu->arch.pause)
|
2015-09-26 05:41:14 +08:00
|
|
|
vcpu_sleep(vcpu);
|
2013-01-21 07:28:13 +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();
|
2015-11-24 17:31:07 +08:00
|
|
|
kvm_timer_flush_hwstate(vcpu);
|
2015-06-08 22:00:28 +08:00
|
|
|
kvm_vgic_flush_hwstate(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
|
|
|
local_irq_disable();
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Re-check atomic conditions
|
|
|
|
*/
|
|
|
|
if (signal_pending(current)) {
|
|
|
|
ret = -EINTR;
|
|
|
|
run->exit_reason = KVM_EXIT_INTR;
|
|
|
|
}
|
|
|
|
|
2015-09-26 05:41:16 +08:00
|
|
|
if (ret <= 0 || need_new_vmid_gen(vcpu->kvm) ||
|
2015-09-26 05:41:17 +08:00
|
|
|
vcpu->arch.power_off || vcpu->arch.pause) {
|
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_enable();
|
arm/arm64: KVM: Rework the arch timer to use level-triggered semantics
The arch timer currently uses edge-triggered semantics in the sense that
the line is never sampled by the vgic and lowering the line from the
timer to the vgic doesn't have any effect on the pending state of
virtual interrupts in the vgic. This means that we do not support a
guest with the otherwise valid behavior of (1) disable interrupts (2)
enable the timer (3) disable the timer (4) enable interrupts. Such a
guest would validly not expect to see any interrupts on real hardware,
but will see interrupts on KVM.
This patch fixes this shortcoming through the following series of
changes.
First, we change the flow of the timer/vgic sync/flush operations. Now
the timer is always flushed/synced before the vgic, because the vgic
samples the state of the timer output. This has the implication that we
move the timer operations in to non-preempible sections, but that is
fine after the previous commit getting rid of hrtimer schedules on every
entry/exit.
Second, we change the internal behavior of the timer, letting the timer
keep track of its previous output state, and only lower/raise the line
to the vgic when the state changes. Note that in theory this could have
been accomplished more simply by signalling the vgic every time the
state *potentially* changed, but we don't want to be hitting the vgic
more often than necessary.
Third, we get rid of the use of the map->active field in the vgic and
instead simply set the interrupt as active on the physical distributor
whenever the input to the GIC is asserted and conversely clear the
physical active state when the input to the GIC is deasserted.
Fourth, and finally, we now initialize the timer PPIs (and all the other
unused PPIs for now), to be level-triggered, and modify the sync code to
sample the line state on HW sync and re-inject a new interrupt if it is
still pending at that time.
Signed-off-by: Christoffer Dall <christoffer.dall@linaro.org>
2015-08-30 21:01:27 +08:00
|
|
|
kvm_timer_sync_hwstate(vcpu);
|
2013-01-22 08:36:12 +08:00
|
|
|
kvm_vgic_sync_hwstate(vcpu);
|
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);
|
|
|
|
|
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));
|
2015-04-30 19:43:31 +08:00
|
|
|
__kvm_guest_enter();
|
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 = IN_GUEST_MODE;
|
|
|
|
|
|
|
|
ret = kvm_call_hyp(__kvm_vcpu_run, vcpu);
|
|
|
|
|
|
|
|
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);
|
|
|
|
|
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
|
|
|
/*
|
|
|
|
* We may have taken a host interrupt in HYP mode (ie
|
|
|
|
* while executing the guest). This interrupt is still
|
|
|
|
* pending, as we haven't serviced it yet!
|
|
|
|
*
|
|
|
|
* We're now back in SVC mode, with interrupts
|
|
|
|
* disabled. Enabling the interrupts now will have
|
|
|
|
* the effect of taking the interrupt again, in SVC
|
|
|
|
* mode this time.
|
|
|
|
*/
|
|
|
|
local_irq_enable();
|
|
|
|
|
|
|
|
/*
|
2015-05-29 02:49:10 +08:00
|
|
|
* We do local_irq_enable() before calling kvm_guest_exit() so
|
|
|
|
* that if a timer interrupt hits while running the guest we
|
|
|
|
* account that tick as being spent in the guest. We enable
|
|
|
|
* preemption after calling kvm_guest_exit() so that if we get
|
|
|
|
* preempted we make sure ticks after that is not counted as
|
|
|
|
* guest time.
|
|
|
|
*/
|
|
|
|
kvm_guest_exit();
|
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
|
|
|
|
arm/arm64: KVM: Rework the arch timer to use level-triggered semantics
The arch timer currently uses edge-triggered semantics in the sense that
the line is never sampled by the vgic and lowering the line from the
timer to the vgic doesn't have any effect on the pending state of
virtual interrupts in the vgic. This means that we do not support a
guest with the otherwise valid behavior of (1) disable interrupts (2)
enable the timer (3) disable the timer (4) enable interrupts. Such a
guest would validly not expect to see any interrupts on real hardware,
but will see interrupts on KVM.
This patch fixes this shortcoming through the following series of
changes.
First, we change the flow of the timer/vgic sync/flush operations. Now
the timer is always flushed/synced before the vgic, because the vgic
samples the state of the timer output. This has the implication that we
move the timer operations in to non-preempible sections, but that is
fine after the previous commit getting rid of hrtimer schedules on every
entry/exit.
Second, we change the internal behavior of the timer, letting the timer
keep track of its previous output state, and only lower/raise the line
to the vgic when the state changes. Note that in theory this could have
been accomplished more simply by signalling the vgic every time the
state *potentially* changed, but we don't want to be hitting the vgic
more often than necessary.
Third, we get rid of the use of the map->active field in the vgic and
instead simply set the interrupt as active on the physical distributor
whenever the input to the GIC is asserted and conversely clear the
physical active state when the input to the GIC is deasserted.
Fourth, and finally, we now initialize the timer PPIs (and all the other
unused PPIs for now), to be level-triggered, and modify the sync code to
sample the line state on HW sync and re-inject a new interrupt if it is
still pending at that time.
Signed-off-by: Christoffer Dall <christoffer.dall@linaro.org>
2015-08-30 21:01:27 +08:00
|
|
|
/*
|
|
|
|
* We must sync the timer state before the vgic state so that
|
|
|
|
* the vgic can properly sample the updated state of the
|
|
|
|
* interrupt line.
|
|
|
|
*/
|
|
|
|
kvm_timer_sync_hwstate(vcpu);
|
|
|
|
|
2013-01-22 08:36:12 +08:00
|
|
|
kvm_vgic_sync_hwstate(vcpu);
|
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
|
|
|
ret = handle_exit(vcpu, run, ret);
|
|
|
|
}
|
|
|
|
|
|
|
|
if (vcpu->sigset_active)
|
|
|
|
sigprocmask(SIG_SETMASK, &sigsaved, NULL);
|
|
|
|
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;
|
|
|
|
unsigned long *ptr;
|
|
|
|
|
|
|
|
if (number == KVM_ARM_IRQ_CPU_IRQ)
|
|
|
|
bit_index = __ffs(HCR_VI);
|
|
|
|
else /* KVM_ARM_IRQ_CPU_FIQ */
|
|
|
|
bit_index = __ffs(HCR_VF);
|
|
|
|
|
|
|
|
ptr = (unsigned long *)&vcpu->arch.irq_lines;
|
|
|
|
if (level)
|
|
|
|
set = test_and_set_bit(bit_index, ptr);
|
|
|
|
else
|
|
|
|
set = test_and_clear_bit(bit_index, ptr);
|
|
|
|
|
|
|
|
/*
|
|
|
|
* 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.
|
|
|
|
*/
|
|
|
|
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;
|
|
|
|
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
|
|
|
|
2013-01-22 08:36:15 +08:00
|
|
|
return kvm_vgic_inject_irq(kvm, vcpu->vcpu_id, irq_num, level);
|
|
|
|
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;
|
|
|
|
|
|
|
|
return kvm_vgic_inject_irq(kvm, 0, irq_num, level);
|
|
|
|
}
|
|
|
|
|
|
|
|
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)
|
|
|
|
{
|
|
|
|
unsigned int i;
|
|
|
|
int phys_target = kvm_target_cpu();
|
|
|
|
|
|
|
|
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. */
|
|
|
|
return kvm_reset_vcpu(vcpu);
|
|
|
|
}
|
|
|
|
|
|
|
|
|
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.
|
|
|
|
*/
|
|
|
|
if (vcpu->arch.has_run_once)
|
|
|
|
stage2_unmap_vm(vcpu->kvm);
|
|
|
|
|
2014-10-16 23:21:16 +08:00
|
|
|
vcpu_reset_hcr(vcpu);
|
|
|
|
|
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))
|
2015-09-26 05:41:14 +08:00
|
|
|
vcpu->arch.power_off = true;
|
2014-10-16 22:14:43 +08:00
|
|
|
else
|
2015-09-26 05:41:14 +08:00
|
|
|
vcpu->arch.power_off = false;
|
2013-11-20 09:43:19 +08:00
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
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;
|
|
|
|
|
|
|
|
switch (ioctl) {
|
|
|
|
case KVM_ARM_VCPU_INIT: {
|
|
|
|
struct kvm_vcpu_init init;
|
|
|
|
|
|
|
|
if (copy_from_user(&init, argp, sizeof(init)))
|
|
|
|
return -EFAULT;
|
|
|
|
|
2013-11-20 09:43:19 +08:00
|
|
|
return kvm_arch_vcpu_ioctl_vcpu_init(vcpu, &init);
|
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
|
|
|
|
|
|
|
if (unlikely(!kvm_vcpu_initialized(vcpu)))
|
|
|
|
return -ENOEXEC;
|
|
|
|
|
2013-01-21 07:28:06 +08:00
|
|
|
if (copy_from_user(®, argp, sizeof(reg)))
|
|
|
|
return -EFAULT;
|
|
|
|
if (ioctl == KVM_SET_ONE_REG)
|
|
|
|
return kvm_arm_set_reg(vcpu, ®);
|
|
|
|
else
|
|
|
|
return kvm_arm_get_reg(vcpu, ®);
|
|
|
|
}
|
|
|
|
case KVM_GET_REG_LIST: {
|
|
|
|
struct kvm_reg_list __user *user_list = argp;
|
|
|
|
struct kvm_reg_list reg_list;
|
|
|
|
unsigned n;
|
|
|
|
|
2013-05-09 06:28:06 +08:00
|
|
|
if (unlikely(!kvm_vcpu_initialized(vcpu)))
|
|
|
|
return -ENOEXEC;
|
|
|
|
|
2013-01-21 07:28:06 +08:00
|
|
|
if (copy_from_user(®_list, user_list, sizeof(reg_list)))
|
|
|
|
return -EFAULT;
|
|
|
|
n = reg_list.n;
|
|
|
|
reg_list.n = kvm_arm_num_regs(vcpu);
|
|
|
|
if (copy_to_user(user_list, ®_list, sizeof(reg_list)))
|
|
|
|
return -EFAULT;
|
|
|
|
if (n < reg_list.n)
|
|
|
|
return -E2BIG;
|
|
|
|
return kvm_arm_copy_reg_indices(vcpu, user_list->reg);
|
|
|
|
}
|
|
|
|
default:
|
|
|
|
return -EINVAL;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2015-01-16 07:58:57 +08:00
|
|
|
/**
|
|
|
|
* kvm_vm_ioctl_get_dirty_log - get and clear the log of dirty pages in a slot
|
|
|
|
* @kvm: kvm instance
|
|
|
|
* @log: slot id and address to which we copy the log
|
|
|
|
*
|
|
|
|
* Steps 1-4 below provide general overview of dirty page logging. See
|
|
|
|
* kvm_get_dirty_log_protect() function description for additional details.
|
|
|
|
*
|
|
|
|
* We call kvm_get_dirty_log_protect() to handle steps 1-3, upon return we
|
|
|
|
* always flush the TLB (step 4) even if previous step failed and the dirty
|
|
|
|
* bitmap may be corrupt. Regardless of previous outcome the KVM logging API
|
|
|
|
* does not preclude user space subsequent dirty log read. Flushing TLB ensures
|
|
|
|
* writes will be marked dirty for next log read.
|
|
|
|
*
|
|
|
|
* 1. Take a snapshot of the bit and clear it if needed.
|
|
|
|
* 2. Write protect the corresponding page.
|
|
|
|
* 3. Copy the snapshot to the userspace.
|
|
|
|
* 4. Flush TLB's if needed.
|
|
|
|
*/
|
2013-01-21 07:28:06 +08:00
|
|
|
int kvm_vm_ioctl_get_dirty_log(struct kvm *kvm, struct kvm_dirty_log *log)
|
|
|
|
{
|
2015-01-16 07:58:57 +08:00
|
|
|
bool is_dirty = false;
|
|
|
|
int r;
|
|
|
|
|
|
|
|
mutex_lock(&kvm->slots_lock);
|
|
|
|
|
|
|
|
r = kvm_get_dirty_log_protect(kvm, log, &is_dirty);
|
|
|
|
|
|
|
|
if (is_dirty)
|
|
|
|
kvm_flush_remote_tlbs(kvm);
|
|
|
|
|
|
|
|
mutex_unlock(&kvm->slots_lock);
|
|
|
|
return r;
|
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: {
|
2015-12-18 19:38:43 +08:00
|
|
|
if (!vgic_present)
|
|
|
|
return -ENXIO;
|
2015-03-05 19:26:06 +08:00
|
|
|
return kvm_vgic_create(kvm, KVM_DEV_TYPE_ARM_VGIC_V2);
|
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: {
|
|
|
|
int err;
|
|
|
|
struct kvm_vcpu_init init;
|
|
|
|
|
|
|
|
err = kvm_vcpu_preferred_target(&init);
|
|
|
|
if (err)
|
|
|
|
return err;
|
|
|
|
|
|
|
|
if (copy_to_user(argp, &init, sizeof(init)))
|
|
|
|
return -EFAULT;
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
2013-01-24 02:18:04 +08:00
|
|
|
default:
|
|
|
|
return -EINVAL;
|
|
|
|
}
|
2013-01-21 07:28:06 +08:00
|
|
|
}
|
|
|
|
|
2013-04-13 02:12:07 +08:00
|
|
|
static void cpu_init_hyp_mode(void *dummy)
|
2013-01-21 07:28:06 +08:00
|
|
|
{
|
2013-05-14 19:11:37 +08:00
|
|
|
phys_addr_t boot_pgd_ptr;
|
|
|
|
phys_addr_t pgd_ptr;
|
2013-01-21 07:28:06 +08:00
|
|
|
unsigned long hyp_stack_ptr;
|
|
|
|
unsigned long stack_page;
|
|
|
|
unsigned long vector_ptr;
|
|
|
|
|
|
|
|
/* Switch from the HYP stub to our own HYP init vector */
|
ARM: KVM: switch to a dual-step HYP init code
Our HYP init code suffers from two major design issues:
- it cannot support CPU hotplug, as we tear down the idmap very early
- it cannot perform a TLB invalidation when switching from init to
runtime mappings, as pages are manipulated from PL1 exclusively
The hotplug problem mandates that we keep two sets of page tables
(boot and runtime). The TLB problem mandates that we're able to
transition from one PGD to another while in HYP, invalidating the TLBs
in the process.
To be able to do this, we need to share a page between the two page
tables. A page that will have the same VA in both configurations. All we
need is a VA that has the following properties:
- This VA can't be used to represent a kernel mapping.
- This VA will not conflict with the physical address of the kernel text
The vectors page seems to satisfy this requirement:
- The kernel never maps anything else there
- The kernel text being copied at the beginning of the physical memory,
it is unlikely to use the last 64kB (I doubt we'll ever support KVM
on a system with something like 4MB of RAM, but patches are very
welcome).
Let's call this VA the trampoline VA.
Now, we map our init page at 3 locations:
- idmap in the boot pgd
- trampoline VA in the boot pgd
- trampoline VA in the runtime pgd
The init scenario is now the following:
- We jump in HYP with four parameters: boot HYP pgd, runtime HYP pgd,
runtime stack, runtime vectors
- Enable the MMU with the boot pgd
- Jump to a target into the trampoline page (remember, this is the same
physical page!)
- Now switch to the runtime pgd (same VA, and still the same physical
page!)
- Invalidate TLBs
- Set stack and vectors
- Profit! (or eret, if you only care about the code).
Note that we keep the boot mapping permanently (it is not strictly an
idmap anymore) to allow for CPU hotplug in later patches.
Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
Signed-off-by: Christoffer Dall <cdall@cs.columbia.edu>
2013-04-13 02:12:06 +08:00
|
|
|
__hyp_set_vectors(kvm_get_idmap_vector());
|
2013-01-21 07:28:06 +08:00
|
|
|
|
2013-05-14 19:11:37 +08:00
|
|
|
boot_pgd_ptr = kvm_mmu_get_boot_httbr();
|
|
|
|
pgd_ptr = kvm_mmu_get_httbr();
|
2013-10-21 20:17:08 +08:00
|
|
|
stack_page = __this_cpu_read(kvm_arm_hyp_stack_page);
|
2013-01-21 07:28:06 +08:00
|
|
|
hyp_stack_ptr = stack_page + PAGE_SIZE;
|
|
|
|
vector_ptr = (unsigned long)__kvm_hyp_vector;
|
|
|
|
|
ARM: KVM: switch to a dual-step HYP init code
Our HYP init code suffers from two major design issues:
- it cannot support CPU hotplug, as we tear down the idmap very early
- it cannot perform a TLB invalidation when switching from init to
runtime mappings, as pages are manipulated from PL1 exclusively
The hotplug problem mandates that we keep two sets of page tables
(boot and runtime). The TLB problem mandates that we're able to
transition from one PGD to another while in HYP, invalidating the TLBs
in the process.
To be able to do this, we need to share a page between the two page
tables. A page that will have the same VA in both configurations. All we
need is a VA that has the following properties:
- This VA can't be used to represent a kernel mapping.
- This VA will not conflict with the physical address of the kernel text
The vectors page seems to satisfy this requirement:
- The kernel never maps anything else there
- The kernel text being copied at the beginning of the physical memory,
it is unlikely to use the last 64kB (I doubt we'll ever support KVM
on a system with something like 4MB of RAM, but patches are very
welcome).
Let's call this VA the trampoline VA.
Now, we map our init page at 3 locations:
- idmap in the boot pgd
- trampoline VA in the boot pgd
- trampoline VA in the runtime pgd
The init scenario is now the following:
- We jump in HYP with four parameters: boot HYP pgd, runtime HYP pgd,
runtime stack, runtime vectors
- Enable the MMU with the boot pgd
- Jump to a target into the trampoline page (remember, this is the same
physical page!)
- Now switch to the runtime pgd (same VA, and still the same physical
page!)
- Invalidate TLBs
- Set stack and vectors
- Profit! (or eret, if you only care about the code).
Note that we keep the boot mapping permanently (it is not strictly an
idmap anymore) to allow for CPU hotplug in later patches.
Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
Signed-off-by: Christoffer Dall <cdall@cs.columbia.edu>
2013-04-13 02:12:06 +08:00
|
|
|
__cpu_init_hyp_mode(boot_pgd_ptr, pgd_ptr, hyp_stack_ptr, vector_ptr);
|
2015-07-08 00:29:56 +08:00
|
|
|
|
|
|
|
kvm_arm_init_debug();
|
2013-01-21 07:28:06 +08:00
|
|
|
}
|
|
|
|
|
2013-04-13 02:12:07 +08:00
|
|
|
static int hyp_init_cpu_notify(struct notifier_block *self,
|
|
|
|
unsigned long action, void *cpu)
|
|
|
|
{
|
|
|
|
switch (action) {
|
|
|
|
case CPU_STARTING:
|
|
|
|
case CPU_STARTING_FROZEN:
|
2014-09-22 22:52:48 +08:00
|
|
|
if (__hyp_get_vectors() == hyp_default_vectors)
|
|
|
|
cpu_init_hyp_mode(NULL);
|
2013-04-13 02:12:07 +08:00
|
|
|
break;
|
|
|
|
}
|
|
|
|
|
|
|
|
return NOTIFY_OK;
|
2013-01-21 07:28:06 +08:00
|
|
|
}
|
|
|
|
|
2013-04-13 02:12:07 +08:00
|
|
|
static struct notifier_block hyp_init_cpu_nb = {
|
|
|
|
.notifier_call = hyp_init_cpu_notify,
|
|
|
|
};
|
|
|
|
|
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)
|
|
|
|
{
|
2014-02-27 02:47:36 +08:00
|
|
|
if (cmd == CPU_PM_EXIT &&
|
|
|
|
__hyp_get_vectors() == hyp_default_vectors) {
|
2013-08-05 22:04:46 +08:00
|
|
|
cpu_init_hyp_mode(NULL);
|
|
|
|
return NOTIFY_OK;
|
|
|
|
}
|
|
|
|
|
|
|
|
return NOTIFY_DONE;
|
|
|
|
}
|
|
|
|
|
|
|
|
static struct notifier_block hyp_init_cpu_pm_nb = {
|
|
|
|
.notifier_call = hyp_init_cpu_pm_notifier,
|
|
|
|
};
|
|
|
|
|
|
|
|
static void __init hyp_cpu_pm_init(void)
|
|
|
|
{
|
|
|
|
cpu_pm_register_notifier(&hyp_init_cpu_pm_nb);
|
|
|
|
}
|
|
|
|
#else
|
|
|
|
static inline void hyp_cpu_pm_init(void)
|
|
|
|
{
|
|
|
|
}
|
|
|
|
#endif
|
|
|
|
|
2013-01-21 07:28:06 +08:00
|
|
|
/**
|
|
|
|
* Inits Hyp-mode on all online CPUs
|
|
|
|
*/
|
|
|
|
static int init_hyp_mode(void)
|
|
|
|
{
|
|
|
|
int cpu;
|
|
|
|
int err = 0;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Allocate Hyp PGD and setup Hyp identity mapping
|
|
|
|
*/
|
|
|
|
err = kvm_mmu_init();
|
|
|
|
if (err)
|
|
|
|
goto out_err;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* It is probably enough to obtain the default on one
|
|
|
|
* CPU. It's unlikely to be different on the others.
|
|
|
|
*/
|
|
|
|
hyp_default_vectors = __hyp_get_vectors();
|
|
|
|
|
|
|
|
/*
|
|
|
|
* 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;
|
|
|
|
goto out_free_stack_pages;
|
|
|
|
}
|
|
|
|
|
|
|
|
per_cpu(kvm_arm_hyp_stack_page, cpu) = stack_page;
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Map the Hyp-code called directly from the host
|
|
|
|
*/
|
|
|
|
err = create_hyp_mappings(__kvm_hyp_code_start, __kvm_hyp_code_end);
|
|
|
|
if (err) {
|
|
|
|
kvm_err("Cannot map world-switch code\n");
|
|
|
|
goto out_free_mappings;
|
|
|
|
}
|
|
|
|
|
2015-10-27 20:18:48 +08:00
|
|
|
err = create_hyp_mappings(__start_rodata, __end_rodata);
|
|
|
|
if (err) {
|
|
|
|
kvm_err("Cannot map rodata section\n");
|
|
|
|
goto out_free_mappings;
|
|
|
|
}
|
|
|
|
|
2013-01-21 07:28:06 +08:00
|
|
|
/*
|
|
|
|
* Map the Hyp stack pages
|
|
|
|
*/
|
|
|
|
for_each_possible_cpu(cpu) {
|
|
|
|
char *stack_page = (char *)per_cpu(kvm_arm_hyp_stack_page, cpu);
|
|
|
|
err = create_hyp_mappings(stack_page, stack_page + PAGE_SIZE);
|
|
|
|
|
|
|
|
if (err) {
|
|
|
|
kvm_err("Cannot map hyp stack\n");
|
|
|
|
goto out_free_mappings;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
2013-04-08 23:47:19 +08:00
|
|
|
* Map the host CPU structures
|
2013-01-21 07:28:06 +08:00
|
|
|
*/
|
2013-04-08 23:47:19 +08:00
|
|
|
kvm_host_cpu_state = alloc_percpu(kvm_cpu_context_t);
|
|
|
|
if (!kvm_host_cpu_state) {
|
2013-01-21 07:28:06 +08:00
|
|
|
err = -ENOMEM;
|
2013-04-08 23:47:19 +08:00
|
|
|
kvm_err("Cannot allocate host CPU state\n");
|
2013-01-21 07:28:06 +08:00
|
|
|
goto out_free_mappings;
|
|
|
|
}
|
|
|
|
|
|
|
|
for_each_possible_cpu(cpu) {
|
2013-04-08 23:47:19 +08:00
|
|
|
kvm_cpu_context_t *cpu_ctxt;
|
2013-01-21 07:28:06 +08:00
|
|
|
|
2013-04-08 23:47:19 +08:00
|
|
|
cpu_ctxt = per_cpu_ptr(kvm_host_cpu_state, cpu);
|
|
|
|
err = create_hyp_mappings(cpu_ctxt, cpu_ctxt + 1);
|
2013-01-21 07:28:06 +08:00
|
|
|
|
|
|
|
if (err) {
|
2013-04-08 23:47:19 +08:00
|
|
|
kvm_err("Cannot map host CPU state: %d\n", err);
|
|
|
|
goto out_free_context;
|
2013-01-21 07:28:06 +08:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2013-04-13 02:12:07 +08:00
|
|
|
/*
|
|
|
|
* Execute the init code on each CPU.
|
|
|
|
*/
|
|
|
|
on_each_cpu(cpu_init_hyp_mode, NULL, 1);
|
|
|
|
|
2013-01-22 08:36:12 +08:00
|
|
|
/*
|
|
|
|
* Init HYP view of VGIC
|
|
|
|
*/
|
|
|
|
err = kvm_vgic_hyp_init();
|
2015-12-18 19:38:43 +08:00
|
|
|
switch (err) {
|
|
|
|
case 0:
|
|
|
|
vgic_present = true;
|
|
|
|
break;
|
|
|
|
case -ENODEV:
|
|
|
|
case -ENXIO:
|
|
|
|
vgic_present = false;
|
|
|
|
break;
|
|
|
|
default:
|
2013-04-08 23:47:19 +08:00
|
|
|
goto out_free_context;
|
2015-12-18 19:38:43 +08:00
|
|
|
}
|
2013-01-22 08:36:12 +08:00
|
|
|
|
2013-01-24 02:21:59 +08:00
|
|
|
/*
|
|
|
|
* Init HYP architected timer support
|
|
|
|
*/
|
|
|
|
err = kvm_timer_hyp_init();
|
|
|
|
if (err)
|
2015-10-06 16:14:35 +08:00
|
|
|
goto out_free_context;
|
2013-01-24 02:21:59 +08:00
|
|
|
|
2013-04-13 02:12:07 +08:00
|
|
|
#ifndef CONFIG_HOTPLUG_CPU
|
|
|
|
free_boot_hyp_pgd();
|
|
|
|
#endif
|
|
|
|
|
2013-03-05 11:18:00 +08:00
|
|
|
kvm_perf_init();
|
|
|
|
|
2015-11-16 19:28:18 +08:00
|
|
|
/* set size of VMID supported by CPU */
|
|
|
|
kvm_vmid_bits = kvm_get_vmid_bits();
|
|
|
|
kvm_info("%d-bit VMID\n", kvm_vmid_bits);
|
|
|
|
|
2013-01-21 07:28:06 +08:00
|
|
|
kvm_info("Hyp mode initialized successfully\n");
|
2013-03-05 11:18:00 +08:00
|
|
|
|
2013-01-21 07:28:06 +08:00
|
|
|
return 0;
|
2013-04-08 23:47:19 +08:00
|
|
|
out_free_context:
|
|
|
|
free_percpu(kvm_host_cpu_state);
|
2013-01-21 07:28:06 +08:00
|
|
|
out_free_mappings:
|
2013-04-13 02:12:05 +08:00
|
|
|
free_hyp_pgds();
|
2013-01-21 07:28:06 +08:00
|
|
|
out_free_stack_pages:
|
|
|
|
for_each_possible_cpu(cpu)
|
|
|
|
free_page(per_cpu(kvm_arm_hyp_stack_page, cpu));
|
|
|
|
out_err:
|
|
|
|
kvm_err("error initializing Hyp mode: %d\n", err);
|
|
|
|
return err;
|
|
|
|
}
|
|
|
|
|
2013-04-17 18:52:01 +08:00
|
|
|
static void check_kvm_target_cpu(void *ret)
|
|
|
|
{
|
|
|
|
*(int *)ret = kvm_target_cpu();
|
|
|
|
}
|
|
|
|
|
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;
|
|
|
|
int i;
|
|
|
|
|
|
|
|
mpidr &= MPIDR_HWID_BITMASK;
|
|
|
|
kvm_for_each_vcpu(i, vcpu, kvm) {
|
|
|
|
if (mpidr == kvm_vcpu_get_mpidr_aff(vcpu))
|
|
|
|
return vcpu;
|
|
|
|
}
|
|
|
|
return NULL;
|
|
|
|
}
|
|
|
|
|
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;
|
2013-04-17 18:52:01 +08:00
|
|
|
int ret, cpu;
|
2013-01-21 07:28:06 +08:00
|
|
|
|
|
|
|
if (!is_hyp_mode_available()) {
|
|
|
|
kvm_err("HYP mode not available\n");
|
|
|
|
return -ENODEV;
|
|
|
|
}
|
|
|
|
|
2013-04-17 18:52:01 +08:00
|
|
|
for_each_online_cpu(cpu) {
|
|
|
|
smp_call_function_single(cpu, check_kvm_target_cpu, &ret, 1);
|
|
|
|
if (ret < 0) {
|
|
|
|
kvm_err("Error, CPU %d not supported!\n", cpu);
|
|
|
|
return -ENODEV;
|
|
|
|
}
|
2013-01-21 07:28:06 +08:00
|
|
|
}
|
|
|
|
|
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
|
|
|
cpu_notifier_register_begin();
|
|
|
|
|
2013-01-21 07:28:06 +08:00
|
|
|
err = init_hyp_mode();
|
|
|
|
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
|
|
|
err = __register_cpu_notifier(&hyp_init_cpu_nb);
|
2013-04-13 02:12:07 +08:00
|
|
|
if (err) {
|
|
|
|
kvm_err("Cannot register HYP init CPU notifier (%d)\n", 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
|
|
|
cpu_notifier_register_done();
|
|
|
|
|
2013-08-05 22:04:46 +08:00
|
|
|
hyp_cpu_pm_init();
|
|
|
|
|
2013-01-21 07:28:09 +08:00
|
|
|
kvm_coproc_table_init();
|
2013-01-21 07:28:06 +08:00
|
|
|
return 0;
|
2013-01-21 07:28:06 +08:00
|
|
|
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
|
|
|
cpu_notifier_register_done();
|
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)
|
|
|
|
{
|
2013-03-05 11:18:00 +08:00
|
|
|
kvm_perf_teardown();
|
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);
|