From mboxrd@z Thu Jan 1 00:00:00 1970 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 Message-ID: <4D497BD1.1040308@redhat.com> References: <4D484A9B.9040604@siemens.com> <20110202115537.GE14984@redhat.com> <4D4946F7.1070702@siemens.com> <20110202123532.GF14984@redhat.com> <4D4952FA.8020300@siemens.com> <4D49569F.6060207@redhat.com> <4D496A8D.90000@siemens.com> <4D496BC5.10807@redhat.com> <4D496D77.2010405@siemens.com> <4D496FA6.8070301@siemens.com> <4D49738D.7080404@redhat.com> <4D4979BD.6080900@siemens.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Gleb Natapov , kvm , qemu-devel To: Jan Kiszka Return-path: Received: from mx1.redhat.com ([209.132.183.28]:30073 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754473Ab1BBPo0 (ORCPT ); Wed, 2 Feb 2011 10:44:26 -0500 In-Reply-To: <4D4979BD.6080900@siemens.com> Sender: kvm-owner@vger.kernel.org List-ID: 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