Mailing List Archive

[PATCH RFC V3 2/4] kvm hypervisor : Add a hypercall to KVM hypervisor to support pv-ticketlocks
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@linux.vnet.ibm.com>
Signed-off-by: Suzuki Poulose <suzuki@in.ibm.com>
Signed-off-by: Raghavendra K T <raghavendra.kt@linux.vnet.ibm.com>
---
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;
+ if (vcpu) {
+ vcpu->kicked = 1;
+ /* Ensure kicked is always set before wakeup */
+ barrier();
+ }
+ kvm_arch_vcpu_ioctl_set_mpstate(vcpu, &mp_state);
+ kvm_vcpu_kick(vcpu);
+}
+
int kvm_emulate_hypercall(struct kvm_vcpu *vcpu)
{
unsigned long nr, a0, a1, a2, a3, ret;
@@ -5341,6 +5363,10 @@ int kvm_emulate_hypercall(struct kvm_vcpu *vcpu)
case KVM_HC_MMU_OP:
r = kvm_pv_mmu_op(vcpu, a0, hc_gpa(vcpu, a1, a2), &ret);
break;
+ case KVM_HC_KICK_CPU:
+ kvm_pv_kick_cpu_op(vcpu->kvm, a0);
+ ret = 0;
+ break;
default:
ret = -KVM_ENOSYS;
break;
diff --git a/include/linux/kvm.h b/include/linux/kvm.h
index f47fcd3..e760035 100644
--- a/include/linux/kvm.h
+++ b/include/linux/kvm.h
@@ -558,6 +558,7 @@ struct kvm_ppc_pvinfo {
#define KVM_CAP_PPC_HIOR 67
#define KVM_CAP_PPC_PAPR 68
#define KVM_CAP_S390_GMAP 71
+#define KVM_CAP_KICK_VCPU 72

#ifdef KVM_CAP_IRQ_ROUTING

diff --git a/include/linux/kvm_host.h b/include/linux/kvm_host.h
index d526231..ff3b6ff 100644
--- a/include/linux/kvm_host.h
+++ b/include/linux/kvm_host.h
@@ -154,6 +154,11 @@ struct kvm_vcpu {
#endif

struct kvm_vcpu_arch arch;
+
+ /*
+ * blocked vcpu wakes up by checking this flag set by unlocker.
+ */
+ int kicked;
};

static inline int kvm_vcpu_exiting_guest_mode(struct kvm_vcpu *vcpu)
diff --git a/include/linux/kvm_para.h b/include/linux/kvm_para.h
index 47a070b..19f10bd 100644
--- a/include/linux/kvm_para.h
+++ b/include/linux/kvm_para.h
@@ -19,6 +19,7 @@
#define KVM_HC_MMU_OP 2
#define KVM_HC_FEATURES 3
#define KVM_HC_PPC_MAP_MAGIC_PAGE 4
+#define KVM_HC_KICK_CPU 5

/*
* hypercalls use architecture specific
diff --git a/virt/kvm/kvm_main.c b/virt/kvm/kvm_main.c
index d9cfb78..8f4b6db 100644
--- a/virt/kvm/kvm_main.c
+++ b/virt/kvm/kvm_main.c
@@ -226,6 +226,7 @@ int kvm_vcpu_init(struct kvm_vcpu *vcpu, struct kvm *kvm, unsigned id)
vcpu->kvm = kvm;
vcpu->vcpu_id = id;
vcpu->pid = NULL;
+ vcpu->kicked = 0;
init_waitqueue_head(&vcpu->wq);
kvm_async_pf_vcpu_init(vcpu);



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel
Re: [PATCH RFC V3 2/4] kvm hypervisor : Add a hypercall to KVM hypervisor to support pv-ticketlocks [ In reply to ]
On 11/30/2011 10:59 AM, 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.

The hypercall needs to be documented in
Documentation/virtual/kvm/hypercalls.txt.

Have you tested it on AMD machines? There are some differences in the
hypercall infrastructure there.

> /* 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

Documentation/virtual/kvm/cpuid.txt.

>
> /* 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:

This is redundant with the feature bit? In general, KVM_CAP is for the
host API, while KVM_FEATURE is for the guest API.

>
> +/*
> + * 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);

There is no guarantee that guest cpu numbers match host vcpu numbers.
Use APIC IDs, and kvm_apic_match_dest().

> + struct kvm_mp_state mp_state;
> +
> + mp_state.mp_state = KVM_MP_STATE_RUNNABLE;
> + if (vcpu) {
> + vcpu->kicked = 1;
> + /* Ensure kicked is always set before wakeup */
> + barrier();
> + }
> + kvm_arch_vcpu_ioctl_set_mpstate(vcpu, &mp_state);

This must only be called from the vcpu thread.

> + kvm_vcpu_kick(vcpu);
> +}
> +
>
> struct kvm_vcpu_arch arch;
> +
> + /*
> + * blocked vcpu wakes up by checking this flag set by unlocker.
> + */
> + int kicked;
>

Write only variable.

An alternative approach is to use an MSR protocol like x2apic ICR.

--
error compiling committee.c: too many arguments to function


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel
Re: [PATCH RFC V3 2/4] kvm hypervisor : Add a hypercall to KVM hypervisor to support pv-ticketlocks [ In reply to ]
[ CCing Jeremy's new email ID ]
Hi Avi,
Thanks for review and inputs.

On 12/01/2011 04:41 PM, Avi Kivity wrote:
> On 11/30/2011 10:59 AM, Raghavendra K T wrote:
>
> The hypercall needs to be documented in
> Documentation/virtual/kvm/hypercalls.txt.
>

Yes, Sure 'll document. hypercalls.txt is a new file right?. also I
have to document APIs in Documentation/virtual/kvm/api.txt.

> Have you tested it on AMD machines? There are some differences in the
> hypercall infrastructure there.

Yes. 'll test on AMD machine and update on that.

>
>> /* 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
>
> Documentation/virtual/kvm/cpuid.txt.

Yes. 'll do that.

>
>>
>> /* 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:
>
> This is redundant with the feature bit? In general, KVM_CAP is for the
> host API, while KVM_FEATURE is for the guest API.
>

No its not. I have to check the flow again. I understood that this
completes the guest querying, that checks for KVM_FEATURE availability.
Did I miss something? I need a little deep dive though.

>>
>> +/*
>> + * 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);
>
> There is no guarantee that guest cpu numbers match host vcpu numbers.
> Use APIC IDs, and kvm_apic_match_dest().

Okay. I have to dig more on this.

>
>> + struct kvm_mp_state mp_state;
>> +
>> + mp_state.mp_state = KVM_MP_STATE_RUNNABLE;
>> + if (vcpu) {
>> + vcpu->kicked = 1;
>> + /* Ensure kicked is always set before wakeup */
>> + barrier();
>> + }
>> + kvm_arch_vcpu_ioctl_set_mpstate(vcpu,&mp_state);
>
> This must only be called from the vcpu thread.

Hmm. Okay. 'll check this.

>
>> + kvm_vcpu_kick(vcpu);
>> +}
>> +
>>
>> struct kvm_vcpu_arch arch;
>> +
>> + /*
>> + * blocked vcpu wakes up by checking this flag set by unlocker.
>> + */
>> + int kicked;
>>
>
> Write only variable.

Yes 'll remove comments.

>
> An alternative approach is to use an MSR protocol like x2apic ICR.
>

'll explore on this too.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel
Re: [PATCH RFC V3 2/4] kvm hypervisor : Add a hypercall to KVM hypervisor to support pv-ticketlocks [ In reply to ]
On 12/02/2011 01:20 AM, Raghavendra K T wrote:
>>> + struct kvm_mp_state mp_state;
>>> +
>>> + mp_state.mp_state = KVM_MP_STATE_RUNNABLE;
>>> + if (vcpu) {
>>> + vcpu->kicked = 1;
>>> + /* Ensure kicked is always set before wakeup */
>>> + barrier();
>>> + }
>>> + kvm_arch_vcpu_ioctl_set_mpstate(vcpu,&mp_state);
>>
>> This must only be called from the vcpu thread.
>
> Hmm. Okay. 'll check this.
>

Yes true. kvm_arch_vcpu_ioctl_set_mpstate itself is redundant, and will
remove this.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel
Re: [PATCH RFC V3 2/4] kvm hypervisor : Add a hypercall to KVM hypervisor to support pv-ticketlocks [ In reply to ]
On 12/02/2011 01:20 AM, Raghavendra K T wrote:
>> Have you tested it on AMD machines? There are some differences in the
>> hypercall infrastructure there.
>
> Yes. 'll test on AMD machine and update on that.
>

I tested the code on 64 bit Dual-Core AMD Opteron machine, and it is
working.

- Raghu


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel
Re: [PATCH RFC V3 2/4] kvm hypervisor : Add a hypercall to KVM hypervisor to support pv-ticketlocks [ In reply to ]
On Sun, Dec 04, 2011 at 11:36:58PM +0530, Raghavendra K T wrote:
> On 12/02/2011 01:20 AM, Raghavendra K T wrote:
> >>Have you tested it on AMD machines? There are some differences in the
> >>hypercall infrastructure there.
> >
> >Yes. 'll test on AMD machine and update on that.
> >
>
> I tested the code on 64 bit Dual-Core AMD Opteron machine, and it is
> working.

I am not that familiar with how KVM does migration, but do you need any
special flags in QEMU to when migrating a KVM-pv-spinlock enabled guest
to another machine?

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel
Re: [PATCH RFC V3 2/4] kvm hypervisor : Add a hypercall to KVM hypervisor to support pv-ticketlocks [ In reply to ]
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@linux.vnet.ibm.com>
> Signed-off-by: Suzuki Poulose <suzuki@in.ibm.com>
> Signed-off-by: Raghavendra K T <raghavendra.kt@linux.vnet.ibm.com>
> ---
> 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@lists.xensource.com
http://lists.xensource.com/xen-devel
Re: [PATCH RFC V3 2/4] kvm hypervisor : Add a hypercall to KVM hypervisor to support pv-ticketlocks [ In reply to ]
On 12/06/2011 06:49 PM, Konrad Rzeszutek Wilk wrote:
> On Sun, Dec 04, 2011 at 11:36:58PM +0530, Raghavendra K T wrote:
> > On 12/02/2011 01:20 AM, Raghavendra K T wrote:
> > >>Have you tested it on AMD machines? There are some differences in the
> > >>hypercall infrastructure there.
> > >
> > >Yes. 'll test on AMD machine and update on that.
> > >
> >
> > I tested the code on 64 bit Dual-Core AMD Opteron machine, and it is
> > working.
>
> I am not that familiar with how KVM does migration, but do you need any
> special flags in QEMU to when migrating a KVM-pv-spinlock enabled guest
> to another machine?

I don't think so. Sleeping is an ordinary HLT state which we already
migrate. There are no further states.

--
error compiling committee.c: too many arguments to function


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel
Re: [PATCH RFC V3 2/4] kvm hypervisor : Add a hypercall to KVM hypervisor to support pv-ticketlocks [ In reply to ]
On 12/07/2011 04:18 PM, Marcelo Tosatti wrote:
> On Wed, Nov 30, 2011 at 02:29:59PM +0530, Raghavendra K T wrote:
>>
>> +/*
>> + * 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?
>

Yes you are right. It was potentially racy and it was harmful too!. I
had observed that it was stalling the CPU before I introduced kicked flag.

But now,

vcpu->kicked = 1 ==> kvm_make_request(KVM_REQ_UNHALT, vcpu); ==>

__vcpu_run() ==> kvm_check_request(KVM_REQ_UNHALT, vcpu) ==>

vcpuN->mp_state = KVM_MP_STATE_RUNNABLE; so eventually we will end up
in RUNNABLE.

Also Avi pointed that, logically kvm_arch_vcpu_ioctl_set_mpstate should
be called only in vcpu thread, so after further debugging, I noticed
that, setting vcpuN->mp_state = KVM_MP_STATE_RUNNABLE; is not
necessary.
I 'll remove that in the next patch. Thanks for pointing.





_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel
Re: [PATCH RFC V3 2/4] kvm hypervisor : Add a hypercall to KVM hypervisor to support pv-ticketlocks [ In reply to ]
On Wed, Dec 07, 2011 at 05:24:59PM +0530, Raghavendra K T wrote:
> On 12/07/2011 04:18 PM, Marcelo Tosatti wrote:
> >On Wed, Nov 30, 2011 at 02:29:59PM +0530, Raghavendra K T wrote:
> >>
> >>+/*
> >>+ * 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?
> >
>
> Yes you are right. It was potentially racy and it was harmful too!.
> I had observed that it was stalling the CPU before I introduced
> kicked flag.
>
> But now,
>
> vcpu->kicked = 1 ==> kvm_make_request(KVM_REQ_UNHALT, vcpu); ==>

Ok, please use a more descriptive name, such as "pvlock_kicked" or
something.

>
> __vcpu_run() ==> kvm_check_request(KVM_REQ_UNHALT, vcpu) ==>
>
> vcpuN->mp_state = KVM_MP_STATE_RUNNABLE; so eventually we will end up
> in RUNNABLE.
>
> Also Avi pointed that, logically kvm_arch_vcpu_ioctl_set_mpstate should
> be called only in vcpu thread, so after further debugging, I noticed
> that, setting vcpuN->mp_state = KVM_MP_STATE_RUNNABLE; is not
> necessary.
> I 'll remove that in the next patch. Thanks for pointing.

In fact you don't need kvm_arch_vcpu_ioctl_set_mpstate either, only the
new "kicked" flag.

>
>
>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel
Re: [PATCH RFC V3 2/4] kvm hypervisor : Add a hypercall to KVM hypervisor to support pv-ticketlocks [ In reply to ]
On 12/07/2011 02:33 PM, Marcelo Tosatti wrote:
> >
> > Also Avi pointed that, logically kvm_arch_vcpu_ioctl_set_mpstate should
> > be called only in vcpu thread, so after further debugging, I noticed
> > that, setting vcpuN->mp_state = KVM_MP_STATE_RUNNABLE; is not
> > necessary.
> > I 'll remove that in the next patch. Thanks for pointing.
>
> In fact you don't need kvm_arch_vcpu_ioctl_set_mpstate either, only the
> new "kicked" flag.

If we have a kicked flag, it becomes necessary to live migrate it.

Maybe we can change KVM_GET_MP_STATE to fold the kicked flag into the mp
state (converting HALTED into RUNNABLE).

Also I think we can keep the kicked flag in vcpu->requests, no need for
new storage.

--
error compiling committee.c: too many arguments to function


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel
Re: [PATCH RFC V3 2/4] kvm hypervisor : Add a hypercall to KVM hypervisor to support pv-ticketlocks [ In reply to ]
On Wed, Dec 07, 2011 at 02:47:05PM +0200, Avi Kivity wrote:
> On 12/07/2011 02:33 PM, Marcelo Tosatti wrote:
> > >
> > > Also Avi pointed that, logically kvm_arch_vcpu_ioctl_set_mpstate should
> > > be called only in vcpu thread, so after further debugging, I noticed
> > > that, setting vcpuN->mp_state = KVM_MP_STATE_RUNNABLE; is not
> > > necessary.
> > > I 'll remove that in the next patch. Thanks for pointing.
> >
> > In fact you don't need kvm_arch_vcpu_ioctl_set_mpstate either, only the
> > new "kicked" flag.
>
> If we have a kicked flag, it becomes necessary to live migrate it.
>
> Maybe we can change KVM_GET_MP_STATE to fold the kicked flag into the mp
> state (converting HALTED into RUNNABLE).

Yep, that works.

> Also I think we can keep the kicked flag in vcpu->requests, no need for
> new storage.

Was going to suggest it but it violates the currently organized
processing of entries at the beginning of vcpu_enter_guest.

That is, this "kicked" flag is different enough from vcpu->requests
processing that a separate variable seems worthwhile (even more
different with convertion to MP_STATE at KVM_GET_MP_STATE).


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel
Re: [PATCH RFC V3 2/4] kvm hypervisor : Add a hypercall to KVM hypervisor to support pv-ticketlocks [ In reply to ]
On 12/07/2011 03:39 PM, Marcelo Tosatti wrote:
> > Also I think we can keep the kicked flag in vcpu->requests, no need for
> > new storage.
>
> Was going to suggest it but it violates the currently organized
> processing of entries at the beginning of vcpu_enter_guest.
>
> That is, this "kicked" flag is different enough from vcpu->requests
> processing that a separate variable seems worthwhile (even more
> different with convertion to MP_STATE at KVM_GET_MP_STATE).

IMO, it's similar to KVM_REQ_EVENT (which can also cause mpstate to
change due to apic re-evaluation).

--
error compiling committee.c: too many arguments to function


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel
Re: [PATCH RFC V3 2/4] kvm hypervisor : Add a hypercall to KVM hypervisor to support pv-ticketlocks [ In reply to ]
On 12/07/2011 06:03 PM, Marcelo Tosatti wrote:
> On Wed, Dec 07, 2011 at 05:24:59PM +0530, Raghavendra K T wrote:
>> On 12/07/2011 04:18 PM, Marcelo Tosatti wrote:
>> Yes you are right. It was potentially racy and it was harmful too!.
>> I had observed that it was stalling the CPU before I introduced
>> kicked flag.
>>
>> But now,
>>
>> vcpu->kicked = 1 ==> kvm_make_request(KVM_REQ_UNHALT, vcpu); ==>
>
> Ok, please use a more descriptive name, such as "pvlock_kicked" or
> something.
>

Yes, pvlock_kicked seems good. 'll use same unless something else
flashes.

>>
>> __vcpu_run() ==> kvm_check_request(KVM_REQ_UNHALT, vcpu) ==>
>>
>> vcpuN->mp_state = KVM_MP_STATE_RUNNABLE; so eventually we will end up
>> in RUNNABLE.
>>
>> Also Avi pointed that, logically kvm_arch_vcpu_ioctl_set_mpstate should
>> be called only in vcpu thread, so after further debugging, I noticed
>> that, setting vcpuN->mp_state = KVM_MP_STATE_RUNNABLE; is not
>> necessary.
>> I 'll remove that in the next patch. Thanks for pointing.
>
> In fact you don't need kvm_arch_vcpu_ioctl_set_mpstate either, only the
> new "kicked" flag.
>

True indeed, I meant the same.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel
Re: [PATCH RFC V3 2/4] kvm hypervisor : Add a hypercall to KVM hypervisor to support pv-ticketlocks [ In reply to ]
On 12/07/2011 08:22 PM, Avi Kivity wrote:
> On 12/07/2011 03:39 PM, Marcelo Tosatti wrote:
>>> Also I think we can keep the kicked flag in vcpu->requests, no need for
>>> new storage.
>>
>> Was going to suggest it but it violates the currently organized
>> processing of entries at the beginning of vcpu_enter_guest.
>>
>> That is, this "kicked" flag is different enough from vcpu->requests
>> processing that a separate variable seems worthwhile (even more
>> different with convertion to MP_STATE at KVM_GET_MP_STATE).
>
> IMO, it's similar to KVM_REQ_EVENT (which can also cause mpstate to
> change due to apic re-evaluation).
>

Ok, So what I understand is we have to either :
1. retain current kick flag AS-IS but would have to make it migration
friendly. [I still have to get more familiar with migration side]
or
2. introduce notion similar to KVM_REQ_PVLOCK_KICK(??) to be part of
vcpu->requests.

So what would be better? Please let me know.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel
Re: [PATCH RFC V3 2/4] kvm hypervisor : Add a hypercall to KVM hypervisor to support pv-ticketlocks [ In reply to ]
On 12/07/2011 06:46 PM, Raghavendra K T wrote:
> On 12/07/2011 08:22 PM, Avi Kivity wrote:
>> On 12/07/2011 03:39 PM, Marcelo Tosatti wrote:
>>>> Also I think we can keep the kicked flag in vcpu->requests, no need
>>>> for
>>>> new storage.
>>>
>>> Was going to suggest it but it violates the currently organized
>>> processing of entries at the beginning of vcpu_enter_guest.
>>>
>>> That is, this "kicked" flag is different enough from vcpu->requests
>>> processing that a separate variable seems worthwhile (even more
>>> different with convertion to MP_STATE at KVM_GET_MP_STATE).
>>
>> IMO, it's similar to KVM_REQ_EVENT (which can also cause mpstate to
>> change due to apic re-evaluation).
>>
>
> Ok, So what I understand is we have to either :
> 1. retain current kick flag AS-IS but would have to make it migration
> friendly. [I still have to get more familiar with migration side]
> or
> 2. introduce notion similar to KVM_REQ_PVLOCK_KICK(??) to be part of
> vcpu->requests.
>
> So what would be better? Please let me know.
>

IMO, KVM_REQ.

--
error compiling committee.c: too many arguments to function


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel
Re: [PATCH RFC V3 2/4] kvm hypervisor : Add a hypercall to KVM hypervisor to support pv-ticketlocks [ In reply to ]
On 12/02/2011 01:20 AM, Raghavendra K T wrote:
>>>
>>> +/*
>>> + * 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);
>>
>> There is no guarantee that guest cpu numbers match host vcpu numbers.
>> Use APIC IDs, and kvm_apic_match_dest().
>
> Okay. I have to dig more on this.
>
Sorry for late reply on this, was experimenting with the changes needed.

Wanted to confirm if it is according to your expectation.

Host side change should look like this to get vcpu,

int i;
struct kvm_vcpu *vcpu = NULL;

kvm_for_each_vcpu(i, vcpu, kvm) {
if (!kvm_apic_present(vcpu))
continue;

if (kvm_apic_match_dest(vcpu, 0, 0, cpu, 0)) {
break;
}
}


In guest side, convert the cpu to apicid using,

apicid = apic->cpu_present_to_apicid(cpu);
OR
apicid = per_cpu(x86_cpu_to_apicid, cpu);

But I have a question, as you know, we are storing the waiting cpus in
cpumask, to track the cpu to be kicked.

You want to change the logic to store the apicid directly instead of
cpu during contention or is it OK to convert before kick hypercall?.

Probably it would be more good if I can get to know the scenario,
where guest cpu numbers does not match host vcpu numbers. It may answer
the whole question and help me in testing/validating the code.

Thanks
- Raghu








_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel
Re: [PATCH RFC V3 2/4] kvm hypervisor : Add a hypercall to KVM hypervisor to support pv-ticketlocks [ In reply to ]
On 12/08/2011 03:10 PM, Avi Kivity wrote:
> On 12/07/2011 06:46 PM, Raghavendra K T wrote:
>> On 12/07/2011 08:22 PM, Avi Kivity wrote:
>>> On 12/07/2011 03:39 PM, Marcelo Tosatti wrote:
>>>>> Also I think we can keep the kicked flag in vcpu->requests, no need
>>>>> for
>>>>> new storage.
>>>>
>>>> Was going to suggest it but it violates the currently organized
>>>> processing of entries at the beginning of vcpu_enter_guest.
>>>>
>>>> That is, this "kicked" flag is different enough from vcpu->requests
>>>> processing that a separate variable seems worthwhile (even more
>>>> different with convertion to MP_STATE at KVM_GET_MP_STATE).
>>>
>>> IMO, it's similar to KVM_REQ_EVENT (which can also cause mpstate to
>>> change due to apic re-evaluation).
>>>
>>
>> Ok, So what I understand is we have to either :
>> 1. retain current kick flag AS-IS but would have to make it migration
>> friendly. [I still have to get more familiar with migration side]
>> or
>> 2. introduce notion similar to KVM_REQ_PVLOCK_KICK(??) to be part of
>> vcpu->requests.
>>
>> So what would be better? Please let me know.
>>
>
> IMO, KVM_REQ.
>

Ok, 'll continue in this direction. Hmm I think now the race condition
should be kept in mind, pointed by Marcello.


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