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

[Avi Kivity <avi@redhat.com>]

On 02/18/2010 11:45 AM, 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.

One way out would be to have a KVM_REQ_IN_PROGRESS, set it in 
make_request, clear it in the IPI function.

If a second make_request sees it already set, it can simply busy wait 
until it is cleared, without sending the IPI.  Of course the busy wait 
means we can't enable preemption (or we may busy wait on an unscheduled 
task), but at least the requests can proceed in parallel instead of 
serializing.

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