On 02/02/2011 05:35 PM, Jan Kiszka wrote:
> > And yet, both are synchronized via qemu_mutex. So we're still missing > something in this picture. > >> Run apic_set_irq on the vcpu? > > static void apic_set_irq(APICState *s, int vector_num, int trigger_mode) > { > apic_irq_delivered += !get_bit(s->irr, vector_num); > > trace_apic_set_irq(apic_irq_delivered); > > set_bit(s->irr, vector_num); > > This is even more async with kernel irqchip > > if (trigger_mode) > set_bit(s->tmr, vector_num); > else > reset_bit(s->tmr, vector_num); > > This is protected by qemu_mutex > > apic_update_irq(s); > > This will be run the next time the vcpu exits, via apic_get_interrupt().The decision to pend an IRQ (and potentially kick the vcpu) takes place immediately in acip_update_irq. And it is based on current irr as well as tpr. But we update again when user space returns with a new value.
Right. My current understanding is that it is correct. But I distinctly remember that I came to a different conclusion when the failure first occurred (and the conclusion was that the patch did not cause the problem, just made it much more likely to see a not-up-to-date TPR).
> > } > > Did you check whether reverting that commit helps? > Just did so, and I can no longer reproduce the problem. Hmm...
At least we have a pointer. -- error compiling committee.c: too many arguments to function -- 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
