Re: [Qemu-devel] [RESEND][PATCH 0/3] Fix guest time drift under heavy load.

[Gleb Natapov <gleb@redhat.com>]

On Sat, Nov 08, 2008 at 12:18:00AM +0100, andrzej zaborowski wrote:
> 2008/11/6 Gleb Natapov <gleb@redhat.com>:
> >> >> >> 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.