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 majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
