From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Kyj6F-0000ot-JC for qemu-devel@nongnu.org; Sat, 08 Nov 2008 03:23:19 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1Kyj6D-0000oh-KJ for qemu-devel@nongnu.org; Sat, 08 Nov 2008 03:23:19 -0500 Received: from [199.232.76.173] (port=55596 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Kyj6D-0000oe-BE for qemu-devel@nongnu.org; Sat, 08 Nov 2008 03:23:17 -0500 Received: from mx20.gnu.org ([199.232.41.8]:18408) by monty-python.gnu.org with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1Kyj6C-0005EX-4D for qemu-devel@nongnu.org; Sat, 08 Nov 2008 03:23:17 -0500 Received: from mx2.redhat.com ([66.187.237.31]) by mx20.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1Kyj69-0000s4-7N for qemu-devel@nongnu.org; Sat, 08 Nov 2008 03:23:13 -0500 Date: Sat, 8 Nov 2008 10:23:16 +0200 From: Gleb Natapov Subject: Re: [Qemu-devel] [RESEND][PATCH 0/3] Fix guest time drift under heavy load. Message-ID: <20081108082316.GA19381@redhat.com> References: <49119551.2070704@redhat.com> <20081106071624.GC3820@redhat.com> <20081106100821.GF3820@redhat.com> <20081106141821.GG3820@redhat.com> <20081106150445.GB29861@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Reply-To: qemu-devel@nongnu.org List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: andrzej zaborowski Cc: dlaor@redhat.com, qemu-devel@nongnu.org On Sat, Nov 08, 2008 at 12:18:00AM +0100, andrzej zaborowski wrote: > 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? > Yes, I was wrong about how RTC behaves. I described how PIT works. PIT generates square wave and does not wait for acknowledgement from an OS. For RTC you suggestion will mostly work and will needlessly re-inject only those ticks that were generated when RTC interrupt vector was masked. Don't know how often this happens in reality. -- Gleb.