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

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

 



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. ]

--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[Index of Archives]     [Kernel Newbies]     [Security]     [Netfilter]     [Bugtraq]     [Linux FS]     [Yosemite Forum]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Samba]     [Video 4 Linux]     [Device Mapper]     [Linux Resources]

  Powered by Linux