Re: [patch] x86: kvm: Convert i8254/i8259 locks to raw_spinlocks

[Avi Kivity <avi@redhat.com>]

On 02/18/2010 11:49 AM, Jan Kiszka wrote:
> Avi Kivity wrote:
>    
>> On 02/18/2010 11:40 AM, Jan Kiszka wrote:
>>      
>>>> Meanwhile, if anyone has any idea how to kill this lock, I'd love to see it.
>>>>
>>>>
>>>>          
>>> What concurrency does it resolve in the end? On first glance, it only
>>> synchronize the fiddling with pre-VCPU request bits, right? What forces
>>> us to do this? Wouldn't it suffice to disable preemption (thus
>>> migration) and the let concurrent requests race for setting the bits? I
>>> mean if some request bit was already set on entry, we don't include the
>>>    related VCPU in smp_call_function_many anyway.
>>>
>>>        
>> It's more difficult.
>>
>> vcpu 0: sets request bit on vcpu 2
>>             vcpu 1: test_and_set request bit on vcpu 2, returns already set
>>             vcpu 1: returns
>> vcpu 0: sends IPI
>> vcpu 0: returns
>>
>> so vcpu 1 returns before the IPI was performed.  If the request was a
>> tlb flush, for example, vcpu 1 may free a page that is still in vcpu 2's
>> tlb.
>>      
> So the requests bits we are interested in are exclusively set in this
> function under requests_lock?
>    

Yes.  vcpu 1 may still see the bit set (if vcpu 2 didn't reach the start 
of its loop and cleared it), so it's not total serialization, but nearly so.

-- 
error compiling committee.c: too many arguments to function