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

[Gleb Natapov]

On Wed, Nov 05, 2008 at 04:48:32PM +0100, andrzej zaborowski wrote:
> > Btw: I ack the whole thing, including the problem, the scenario and the
> > solution.
> 
> I don't, as far as I understand it's a -win2k-hack type of addition,
> i.e. the hardware doesn't do this but we want to improve usability by
> working around a bad guest behaviour.  Modifying qemu_irq abstraction
> doesn't sound like the right place for that, qemu_irq contrary to what
> the name suggests doesn't have to be connected to any interrupt.
> 
It is nothing like a -win2k-hack since there is no any guest "bad
behaviour" that cause the problem. Yes real hardware doesn't do this,
but real hardware also provides OS with enough CPU power to handle every
single timer interrupt. And even if _some_ interrupts are dropped the
drift is easily fixed with NTP. Try to run Windows XP on very slow machine
and I am sure you'll see very noticeable time drift.

> Instead you can have the interrupt sources register a callback in the
> PIC that the PIC calls when the interrupt wasn't delivered.  Or.. in
It requires the mapping from interrupt vector inside the PIC to
interrupt source. This approach was rejected long time ago.

> the case of mc146818rtc.c wouldn't it be enough to check if the irq
> has been acked by reading RTC_REG_C?  e.g.
> 
> static void rtc_periodic_timer(void *opaque)
> {
>     RTCState *s = opaque;
> 
>     rtc_timer_update(s, s->next_periodic_time);
> +   if (s->cmos_data[RTC_REG_C] & 0xc0)
> +         s->irq_coalesced++;
>     s->cmos_data[RTC_REG_C] |= 0xc0;
>     qemu_irq_raise(s->irq);
> }
> 
PIC/APIC in effect has a queue of one interrupt. This means that if
timer tick is still not acknowledged it doesn't mean that interrupt
was not queued for delivery inside a PIC. With your suggestion more
interrupt will be delivered to a guest that was actually issued.

--
                        Gleb.