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>
|
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);
|
|
|
|
static u8 kvm_next_vmid;
|
|
|
|
static DEFINE_SPINLOCK(kvm_vmid_lock);
|
2013-01-21 07:28:06 +08:00
|
|
|
|
2013-01-22 08:36:12 +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;
|
|
|
|
|
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;
|
|
|
|
|
|
|
|
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:
|
|
|
|
r = vgic_present;
|
|
|
|
break;
|
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:
|
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;
|
|
|
|
}
|
|
|
|
|
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);
|
|
|
|
}
|
|
|
|
|
|
|
|
int kvm_arch_vcpu_postcreate(struct kvm_vcpu *vcpu)
|
|
|
|
{
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
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)
|
|
|
|
{
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
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);
|
|
|
|
|
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
|
|
|
|
|
|
|
/*
|
|
|
|
* Check whether this vcpu requires the cache to be flushed on
|
|
|
|
* this physical CPU. This is a consequence of doing dcache
|
|
|
|
* operations by set/way on this vcpu. We do it here to be in
|
|
|
|
* a non-preemptible section.
|
|
|
|
*/
|
|
|
|
if (cpumask_test_and_clear_cpu(cpu, &vcpu->arch.require_dcache_flush))
|
|
|
|
flush_cache_all(); /* We'd really want v7_flush_dcache_all() */
|
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_set_guest_debug(struct kvm_vcpu *vcpu,
|
|
|
|
struct kvm_guest_debug *dbg)
|
|
|
|
{
|
|
|
|
return -EINVAL;
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
int kvm_arch_vcpu_ioctl_get_mpstate(struct kvm_vcpu *vcpu,
|
|
|
|
struct kvm_mp_state *mp_state)
|
|
|
|
{
|
|
|
|
return -EINVAL;
|
|
|
|
}
|
|
|
|
|
|
|
|
int kvm_arch_vcpu_ioctl_set_mpstate(struct kvm_vcpu *vcpu,
|
|
|
|
struct kvm_mp_state *mp_state)
|
|
|
|
{
|
|
|
|
return -EINVAL;
|
|
|
|
}
|
|
|
|
|
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)
|
|
|
|
{
|
2013-01-22 08:36:12 +08:00
|
|
|
return !!v->arch.irq_lines || kvm_vgic_vcpu_pending_irq(v);
|
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++;
|
|
|
|
|
|
|
|
/* 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);
|
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
|
|
|
vmid = ((u64)(kvm->arch.vmid) << VTTBR_VMID_SHIFT) & VTTBR_VMID_MASK;
|
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
|
|
|
*/
|
2014-12-13 04:19:23 +08:00
|
|
|
if (unlikely(!vgic_ready(kvm))) {
|
|
|
|
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;
|
|
|
|
}
|
|
|
|
|
2013-01-21 07:28:13 +08:00
|
|
|
static void vcpu_pause(struct kvm_vcpu *vcpu)
|
|
|
|
{
|
|
|
|
wait_queue_head_t *wq = kvm_arch_vcpu_wq(vcpu);
|
|
|
|
|
|
|
|
wait_event_interruptible(*wq, !vcpu->arch.pause);
|
|
|
|
}
|
|
|
|
|
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);
|
|
|
|
|
2013-01-21 07:28:13 +08:00
|
|
|
if (vcpu->arch.pause)
|
|
|
|
vcpu_pause(vcpu);
|
|
|
|
|
2013-01-22 08:36:12 +08:00
|
|
|
kvm_vgic_flush_hwstate(vcpu);
|
2013-01-24 02:21:59 +08:00
|
|
|
kvm_timer_flush_hwstate(vcpu);
|
2013-01-22 08:36:12 +08:00
|
|
|
|
KVM: ARM: World-switch implementation
Provides complete world-switch implementation to switch to other guests
running in non-secure modes. Includes Hyp exception handlers that
capture necessary exception information and stores the information on
the VCPU and KVM structures.
The following Hyp-ABI is also documented in the code:
Hyp-ABI: Calling HYP-mode functions from host (in SVC mode):
Switching to Hyp mode is done through a simple HVC #0 instruction. The
exception vector code will check that the HVC comes from VMID==0 and if
so will push the necessary state (SPSR, lr_usr) on the Hyp stack.
- r0 contains a pointer to a HYP function
- r1, r2, and r3 contain arguments to the above function.
- The HYP function will be called with its arguments in r0, r1 and r2.
On HYP function return, we return directly to SVC.
A call to a function executing in Hyp mode is performed like the following:
<svc code>
ldr r0, =BSYM(my_hyp_fn)
ldr r1, =my_param
hvc #0 ; Call my_hyp_fn(my_param) from HYP mode
<svc code>
Otherwise, the world-switch is pretty straight-forward. All state that
can be modified by the guest is first backed up on the Hyp stack and the
VCPU values is loaded onto the hardware. State, which is not loaded, but
theoretically modifiable by the guest is protected through the
virtualiation features to generate a trap and cause software emulation.
Upon guest returns, all state is restored from hardware onto the VCPU
struct and the original state is restored from the Hyp-stack onto the
hardware.
SMP support using the VMPIDR calculated on the basis of the host MPIDR
and overriding the low bits with KVM vcpu_id contributed by Marc Zyngier.
Reuse of VMIDs has been implemented by Antonios Motakis and adapated from
a separate patch into the appropriate patches introducing the
functionality. Note that the VMIDs are stored per VM as required by the ARM
architecture reference manual.
To support VFP/NEON we trap those instructions using the HPCTR. When
we trap, we switch the FPU. After a guest exit, the VFP state is
returned to the host. When disabling access to floating point
instructions, we also mask FPEXC_EN in order to avoid the guest
receiving Undefined instruction exceptions before we have a chance to
switch back the floating point state. We are reusing vfp_hard_struct,
so we depend on VFPv3 being enabled in the host kernel, if not, we still
trap cp10 and cp11 in order to inject an undefined instruction exception
whenever the guest tries to use VFP/NEON. VFP/NEON developed by
Antionios Motakis and Rusty Russell.
Aborts that are permission faults, and not stage-1 page table walk, do
not report the faulting address in the HPFAR. We have to resolve the
IPA, and store it just like the HPFAR register on the VCPU struct. If
the IPA cannot be resolved, it means another CPU is playing with the
page tables, and we simply restart the guest. This quirk was fixed by
Marc Zyngier.
Reviewed-by: Will Deacon <will.deacon@arm.com>
Reviewed-by: Marcelo Tosatti <mtosatti@redhat.com>
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Signed-off-by: Antonios Motakis <a.motakis@virtualopensystems.com>
Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
Signed-off-by: Christoffer Dall <c.dall@virtualopensystems.com>
2013-01-21 07:47:42 +08:00
|
|
|
local_irq_disable();
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Re-check atomic conditions
|
|
|
|
*/
|
|
|
|
if (signal_pending(current)) {
|
|
|
|
ret = -EINTR;
|
|
|
|
run->exit_reason = KVM_EXIT_INTR;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (ret <= 0 || need_new_vmid_gen(vcpu->kvm)) {
|
|
|
|
local_irq_enable();
|
2013-01-24 02:21:59 +08:00
|
|
|
kvm_timer_sync_hwstate(vcpu);
|
2013-01-22 08:36:12 +08:00
|
|
|
kvm_vgic_sync_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
|
|
|
continue;
|
|
|
|
}
|
|
|
|
|
|
|
|
/**************************************************************
|
|
|
|
* Enter the guest
|
|
|
|
*/
|
|
|
|
trace_kvm_entry(*vcpu_pc(vcpu));
|
|
|
|
kvm_guest_enter();
|
|
|
|
vcpu->mode = IN_GUEST_MODE;
|
|
|
|
|
|
|
|
ret = kvm_call_hyp(__kvm_vcpu_run, vcpu);
|
|
|
|
|
|
|
|
vcpu->mode = OUTSIDE_GUEST_MODE;
|
2013-01-21 07:28:09 +08:00
|
|
|
vcpu->arch.last_pcpu = smp_processor_id();
|
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_guest_exit();
|
|
|
|
trace_kvm_exit(*vcpu_pc(vcpu));
|
|
|
|
/*
|
|
|
|
* 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();
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Back from guest
|
|
|
|
*************************************************************/
|
|
|
|
|
2013-01-24 02:21:59 +08:00
|
|
|
kvm_timer_sync_hwstate(vcpu);
|
2013-01-22 08:36:12 +08:00
|
|
|
kvm_vgic_sync_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
|
|
|
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;
|
|
|
|
|
|
|
|
if (irq_num < VGIC_NR_PRIVATE_IRQS ||
|
|
|
|
irq_num > KVM_ARM_IRQ_GIC_MAX)
|
|
|
|
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
|
|
|
/*
|
|
|
|
* Handle the "start in power-off" case by marking the VCPU as paused.
|
|
|
|
*/
|
2014-12-02 22:27:51 +08:00
|
|
|
if (test_bit(KVM_ARM_VCPU_POWER_OFF, vcpu->arch.features))
|
2013-11-20 09:43:19 +08:00
|
|
|
vcpu->arch.pause = true;
|
2014-10-16 22:14:43 +08:00
|
|
|
else
|
|
|
|
vcpu->arch.pause = 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
|
|
|
#ifdef CONFIG_ARM
|
|
|
|
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;
|
|
|
|
#else /* arm64 */
|
2013-01-21 07:28:06 +08:00
|
|
|
return -EINVAL;
|
2015-01-16 07:58:57 +08:00
|
|
|
#endif
|
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:
|
|
|
|
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: {
|
|
|
|
if (vgic_present)
|
|
|
|
return kvm_vgic_create(kvm);
|
|
|
|
else
|
|
|
|
return -ENXIO;
|
|
|
|
}
|
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);
|
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;
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* 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();
|
|
|
|
if (err)
|
2013-04-08 23:47:19 +08:00
|
|
|
goto out_free_context;
|
2013-01-22 08:36:12 +08:00
|
|
|
|
2013-01-22 08:36:16 +08:00
|
|
|
#ifdef CONFIG_KVM_ARM_VGIC
|
|
|
|
vgic_present = true;
|
|
|
|
#endif
|
|
|
|
|
2013-01-24 02:21:59 +08:00
|
|
|
/*
|
|
|
|
* Init HYP architected timer support
|
|
|
|
*/
|
|
|
|
err = kvm_timer_hyp_init();
|
|
|
|
if (err)
|
|
|
|
goto out_free_mappings;
|
|
|
|
|
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();
|
|
|
|
|
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();
|
|
|
|
}
|
|
|
|
|
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);
|