Thread (49 messages) 49 messages, 8 authors, 2012-01-25

Re: [PATCH RFC V4 4/5] kvm : pv-ticketlocks support for linux guests running on KVM hypervisor

From: Srivatsa Vaddagiri <hidden>
Date: 2012-01-18 13:54:46
Also in: kvm, xen-devel

* Jeremy Fitzhardinge [off-list ref] [2012-01-18 12:34:42]:
quoted
quoted
What prevents a kick from being lost here, if say, the waiter is at
local_irq_save in kvm_lock_spinning, before the lock/want assignments?
The waiter does check for lock becoming available before actually
sleeping:

+	/*
+        * check again make sure it didn't become free while
+        * we weren't looking.
+        */
+	if (ACCESS_ONCE(lock->tickets.head) == want) {
+               add_stats(TAKEN_SLOW_PICKUP, 1);
+               goto out;
+	}
That logic relies on the "kick" being level triggered, so that "kick"
before "block" will cause the block to fall out immediately.  If you're
using "hlt" as the block and it has the usual edge-triggered behaviour,
what stops a "kick-before-hlt" from losing the kick?
Hmm ..'hlt' should result in a check for kick request (in hypervisor
context) before vcpu is put to sleep. IOW vcpu1 that is attempting to kick vcpu0
will set a 'somebody_tried_kicking_vcpu0' flag, which hypervisor should check 
before it puts vcpu0 to sleep because of trapped 'hlt' instruction.

Won't that trap the 'kick-before-hlt' case? What am I missing here?

- vatsa
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help