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

[Jeremy Fitzhardinge <jeremy@xxxxxxxx>]

On 01/17/2012 10:33 PM, Srivatsa Vaddagiri wrote:
> * Marcelo Tosatti <mtosatti@xxxxxxxxxx> [2012-01-17 09:02:11]:
>
>>> +/* Kick vcpu waiting on @lock->head to reach value @ticket */
>>> +static void kvm_unlock_kick(struct arch_spinlock *lock, __ticket_t ticket)
>>> +{
>>> +   int cpu;
>>> +   int apicid;
>>> +
>>> +   add_stats(RELEASED_SLOW, 1);
>>> +
>>> +   for_each_cpu(cpu, &waiting_cpus) {
>>> +           const struct kvm_lock_waiting *w = &per_cpu(lock_waiting, cpu);
>>> +           if (ACCESS_ONCE(w->lock) == lock &&
>>> +               ACCESS_ONCE(w->want) == ticket) {
>>> +                   add_stats(RELEASED_SLOW_KICKED, 1);
>>> +                   apicid = per_cpu(x86_cpu_to_apicid, cpu);
>>> +                   kvm_kick_cpu(apicid);
>>> +                   break;
>>> +           }
>>> +   }
>> 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?

    J

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel