On Tue, Jul 22, 2008 at 10:22:00AM +0200, Jan Kiszka wrote:
> > The in-kernel PIT rearms relative to host clock, so the frequency is
> > more reliable (next_expiration = prev_expiration + count).
>
> The same happens under plain QEMU:
>
> static void pit_irq_timer_update(PITChannelState *s, int64_t current_time);
>
> static void pit_irq_timer(void *opaque)
> {
> PITChannelState *s = opaque;
>
> pit_irq_timer_update(s, s->next_transition_time);
> }
True. I misread "current_time".
> To my experience QEMU's PIT is suffering from lost ticks under load
> (when some delay gets larger than 2*period).
Yes, with clock=pit on RHEL4 its quite noticeable. Even with -tdf. The
in-kernel timer seems immune to that under the load I was testing.
> I recently played a bit with QEMU new icount feature. Than one tracks
> the guest progress based on a virtual instruction pointer, derives the
> QEMU's virtual clock from it, but also tries to keep that clock in sync
> with the host by periodically adjusting its scaling factor (kind of
> virtual CPU frequency tuning to keep the TSC in sync with real time).
> Works quite nicely, but my feeling is that the adjustment is not 100%
> stable yet.
>
> Maybe such pattern could be applied on kvm as well with tsc_vmexit -
> tsc_vmentry serving as "guest progress counter" (instead of icount which
> depends on QEMU's code translator).
I see. Do you have patches around?
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
