Re: [PATCH v4 2/2] KVM: VMX: Add Posted Interrupt supporting

[Gleb Natapov <gleb@redhat.com>]

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?

--
			Gleb.