[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] [PATCH RFC V3 2/4] kvm hypervisor : Add a hypercall to KVM hypervisor to support pv-ticketlocks



On Wed, Nov 30, 2011 at 02:29:59PM +0530, Raghavendra K T wrote:
> Add a hypercall to KVM hypervisor to support pv-ticketlocks 
> 
> KVM_HC_KICK_CPU allows the calling vcpu to kick another vcpu out of halt 
> state.
>     
> The presence of these hypercalls is indicated to guest via
> KVM_FEATURE_KICK_VCPU/KVM_CAP_KICK_VCPU.
> 
> Qemu needs a corresponding patch to pass up the presence of this feature to 
> guest via cpuid. Patch to qemu will be sent separately.
> 
> There is no Xen/KVM hypercall interface to await kick from.
>     
> Signed-off-by: Srivatsa Vaddagiri <vatsa@xxxxxxxxxxxxxxxxxx>
> Signed-off-by: Suzuki Poulose <suzuki@xxxxxxxxxx>
> Signed-off-by: Raghavendra K T <raghavendra.kt@xxxxxxxxxxxxxxxxxx>
> ---
> diff --git a/arch/x86/include/asm/kvm_para.h b/arch/x86/include/asm/kvm_para.h
> index 734c376..8b1d65d 100644
> --- a/arch/x86/include/asm/kvm_para.h
> +++ b/arch/x86/include/asm/kvm_para.h
> @@ -16,12 +16,14 @@
>  #define KVM_FEATURE_CLOCKSOURCE              0
>  #define KVM_FEATURE_NOP_IO_DELAY     1
>  #define KVM_FEATURE_MMU_OP           2
> +
>  /* This indicates that the new set of kvmclock msrs
>   * are available. The use of 0x11 and 0x12 is deprecated
>   */
>  #define KVM_FEATURE_CLOCKSOURCE2        3
>  #define KVM_FEATURE_ASYNC_PF         4
>  #define KVM_FEATURE_STEAL_TIME               5
> +#define KVM_FEATURE_KICK_VCPU                6
>  
>  /* The last 8 bits are used to indicate how to interpret the flags field
>   * in pvclock structure. If no bits are set, all flags are ignored.
> diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
> index c38efd7..6e1c8b4 100644
> --- a/arch/x86/kvm/x86.c
> +++ b/arch/x86/kvm/x86.c
> @@ -2103,6 +2103,7 @@ int kvm_dev_ioctl_check_extension(long ext)
>       case KVM_CAP_XSAVE:
>       case KVM_CAP_ASYNC_PF:
>       case KVM_CAP_GET_TSC_KHZ:
> +     case KVM_CAP_KICK_VCPU:
>               r = 1;
>               break;
>       case KVM_CAP_COALESCED_MMIO:
> @@ -2577,7 +2578,8 @@ static void do_cpuid_ent(struct kvm_cpuid_entry2 
> *entry, u32 function,
>                            (1 << KVM_FEATURE_NOP_IO_DELAY) |
>                            (1 << KVM_FEATURE_CLOCKSOURCE2) |
>                            (1 << KVM_FEATURE_ASYNC_PF) |
> -                          (1 << KVM_FEATURE_CLOCKSOURCE_STABLE_BIT);
> +                          (1 << KVM_FEATURE_CLOCKSOURCE_STABLE_BIT) |
> +                          (1 << KVM_FEATURE_KICK_VCPU);
>  
>               if (sched_info_on())
>                       entry->eax |= (1 << KVM_FEATURE_STEAL_TIME);
> @@ -5305,6 +5307,26 @@ int kvm_hv_hypercall(struct kvm_vcpu *vcpu)
>       return 1;
>  }
>  
> +/*
> + * kvm_pv_kick_cpu_op:  Kick a vcpu.
> + *
> + * @cpu - vcpu to be kicked.
> + */
> +static void kvm_pv_kick_cpu_op(struct kvm *kvm, int cpu)
> +{
> +     struct kvm_vcpu *vcpu = kvm_get_vcpu(kvm, cpu);
> +     struct kvm_mp_state mp_state;
> +
> +     mp_state.mp_state = KVM_MP_STATE_RUNNABLE;

Since vcpu->mp_state is not protected by a lock, this is potentially racy. For 
example:

CPU0                                            CPU1
kvm_pv_kick_cpu_op                              running vcpuN
vcpuN->mp_state = KVM_MP_STATE_RUNNABLE;
                                                kvm_emulate_halt
                                                vcpuN->mp_state = 
KVM_MP_STATE_HALTED

Is it harmless to lose a kick?


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.