On Sun, Feb 24, 2013 at 02:26:36PM +0000, Zhang, Yang Z wrote:
> > 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?
>
Yes, as far as I can see we cannot reliably implement KVM's
KVM_IRQ_LINE_STATUS interface with given HW interface. Now we should
think about how to minimize the damage.
--
Gleb.
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
