* 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