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

["andrzej zaborowski" <balrogg@gmail.com>]

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?

Cheers