From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Kyaaa-0003dN-Ol for qemu-devel@nongnu.org; Fri, 07 Nov 2008 18:18:04 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1KyaaZ-0003bf-5a for qemu-devel@nongnu.org; Fri, 07 Nov 2008 18:18:04 -0500 Received: from [199.232.76.173] (port=41308 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1KyaaY-0003bN-UJ for qemu-devel@nongnu.org; Fri, 07 Nov 2008 18:18:02 -0500 Received: from rv-out-0708.google.com ([209.85.198.242]:36761) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1KyaaY-0002lo-Jc for qemu-devel@nongnu.org; Fri, 07 Nov 2008 18:18:02 -0500 Received: by rv-out-0708.google.com with SMTP id f25so1345795rvb.22 for ; Fri, 07 Nov 2008 15:18:00 -0800 (PST) Message-ID: Date: Sat, 8 Nov 2008 00:18:00 +0100 From: "andrzej zaborowski" Subject: Re: [Qemu-devel] [RESEND][PATCH 0/3] Fix guest time drift under heavy load. In-Reply-To: <20081106150445.GB29861@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <490B59BF.3000205@codemonkey.ws> <49119551.2070704@redhat.com> <20081106071624.GC3820@redhat.com> <20081106100821.GF3820@redhat.com> <20081106141821.GG3820@redhat.com> <20081106150445.GB29861@redhat.com> Reply-To: qemu-devel@nongnu.org List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Gleb Natapov Cc: dlaor@redhat.com, qemu-devel@nongnu.org 2008/11/6 Gleb Natapov : >> >> >> This doesn't matter, the tick that arrived while a previous interrupt >> >> >> was not acked yet, is lost anyway, >> >> > Not it is not. Not necessary. It can be queued inside PIC and delivered >> >> > by PIC itself immediately after interrupt acknowledgement. >> >> >> >> You can argue that it's the new irq that's lost or it's the first one >> >> that was lost, either way the PIC only sees one time the irq rising, >> >> instead of two. That means they were coalesced. >> > Nothing is lost and PIC sees two irq rising. Example: >> > - RTC triggers first interrupt. >> > - It is delivered to PIC. PIC sets corespondent bit in IRR. >> > - CPU picks up RTC interrupt and it's bit is cleared from IRR bitmap. >> > - CPU jumps to RTC IRQ routing but before it gets a chance to acknowledge >> > IRQ to PIC new timer is triggered. >> > - With your patch you increment irq_coalesced in that case. >> > - Interrupt is delivered to PIC. >> >> No, it isn't (unless the PIC is poorly implemented). We raise the >> irq, but since it's already high, nothing happens, there's no rising >> edge. >> > That would be the case if RTC used level triggered interrupts, but > RTC and PIT are edge-trigered. That is how they behave like it or not. Sorry, I'm not taking this at all. If this was the case it would be completely broken, but I just had a look at i8259 and the implementation seems to be correct. The two devices are connected with only one line. The signal on the line can be in one of two states (levels). After the first tick it becomes high. It stays high until a read to RTC_REG_C clears it. The second call to qemu_irq_raise does not change the level, there's no edge. If there's no event, how possibly can there be a reaction? Cheers