Gleb Natapov wrote on 2013-02-24:
> On Sun, Feb 24, 2013 at 01:55:07PM +0000, Zhang, Yang Z wrote:
>>> I do not think it fixes it. There is no guaranty that IPI will be
>>> processed by remote cpu while sending cpu is still in locked section, so
>>> the same race may happen regardless. As you say above there are 3
>>> contexts, but only two use locks.
>> See following logic, I think the problem you mentioned will not
>> happened with current logic.
>>
>> get lock
>> if test_pir (this will ensure there is no in flight IPI for same interrupt.
>> Since we
> are taking the lock now, no IPI will be sent before we release the lock and no
> pir->irr is performed by hardware for same interrupt.)
> I do not see where those assumptions are coming from. Testing pir does
> not guaranty that the IPI is not processed by VCPU right now.
>
> iothread: vcpu:
> send_irq()
> lock(pir)
> check pir and irr
> set pir
> send IPI (*)
> unlock(pir)
>
> send_irq()
> lock(pir)
> receive IPI (*)
> atomic {
> pir_tmp = pir
> pir = 0
> } check pir and irr irr &= pir_tmp
> set pir
> send IPI
> unlock(pir)
>
> At this point both pir and irr are set and interrupt may be coalesced,
> but it is reported as delivered.
>
> So what prevents the scenario above from happening?
Yes, you are right. For this case, it can do nothing. And we cannot solve this
problem in current KVM, right?
Best regards,
Yang
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
