Re: [Xen-devel] [PATCH RFC V6 1/5] kvm hypervisor : Add a hypercall to KVM hypervisor to support pv-ticketlocks

[Raghavendra K T <raghavendra.kt@xxxxxxxxxxxxxxxxxx>]

On 04/24/2012 03:29 PM, Gleb Natapov wrote:
> On Mon, Apr 23, 2012 at 03:29:47PM +0530, Raghavendra K T wrote:
> > From: Srivatsa Vaddagiri<vatsa@xxxxxxxxxxxxxxxxxx>
[...]
> > diff --git a/virt/kvm/kvm_main.c b/virt/kvm/kvm_main.c
> > index 42b7393..edf56d4 100644
> > --- a/virt/kvm/kvm_main.c
> > +++ b/virt/kvm/kvm_main.c
> > @@ -1500,6 +1500,14 @@ void kvm_vcpu_block(struct kvm_vcpu *vcpu)
> >                 prepare_to_wait(&vcpu->wq,&wait, TASK_INTERRUPTIBLE);
> >
> >                 if (kvm_arch_vcpu_runnable(vcpu)) {
> > +                       /*
> > +                        * This is the only safe place to reset unhalt flag.
> > +                        * otherwise it results in loosing the notification
> > +                        * which eventually can result in vcpu hangs.
> > +                        */
> Why this is the only safe place? Why clearing it in kvm/x86.c just after
> call to kvm_vcpu_block() if KVM_REQ_UNHALT is set is not safe enough?
Yes, You are Right. The acceptable window to reset the flag can be
extended till there. and Good point about that is it removes the need
for having the stubs for other archs and simplifies everything a lot. 
Thanks for that.
[ When I was experimenting with request bit, clearing request bit in the 
same place was causing vm hang after some 16 iteration of stress test. I 
had carried the same impression. Now I have done stress testing
to ensure that the change works.  Basically as you know, my fear was 
loosing kick(s) leads to vm hang eventually. ]

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel