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

[Srivatsa Vaddagiri <vatsa@linux.vnet.ibm.com>]

* Jeremy Fitzhardinge <jeremy@goop.org> [2012-01-18 12:34:42]:

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