|
From: | Avi Kivity |
Subject: | Re: [Qemu-devel] KVM: Windows 64-bit troubles with user space irqchip |
Date: | Wed, 02 Feb 2011 17:44:17 +0200 |
User-agent: | Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.13) Gecko/20101209 Fedora/3.1.7-0.35.b3pre.fc14 Lightning/1.0b3pre Thunderbird/3.1.7 |
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
[Prev in Thread] | Current Thread | [Next in Thread] |