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

[Jan Kiszka <jan.kiszka@siemens.com>]

Avi Kivity wrote:
> 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.

...or include VCPUs with KVM_REQ_IN_PROGRESS set into the IPI set even
if they already have the desired request bit set. Then we should
serialize in smp_call_function_many.

Jan

-- 
Siemens AG, Corporate Technology, CT T DE IT 1
Corporate Competence Center Embedded Linux