Re: [Qemu-devel] [PATCH 1/2] Add HPET emulation to qemu (v3)

[Beth Kon <eak@us.ibm.com>]

On Mon, 2008-10-27 at 12:49 +0200, Dor Laor wrote:
> Beth Kon wrote: 
> > On Fri, 2008-10-17 at 16:49 +0100, Jamie Lokier wrote:
> >   
> > > Beth Kon wrote:
> > >     
> > > > Clock drift on Linux is in the range of .017% - .019%, loaded and unloaded. I
> > > > haven't found a straightforward way to test on Windows and would appreciate
> > > > any pointers to existing approaches.
> > > >       
> > > Is there any reason why there should be any clock drift, when the
> > > guest is using a non-PIT clock?
> > > 
> > > I'm probably being naive, but with 32-bit or 64-bit HPET counters
> > > available to the guest, and accurate values from the CMOS clock
> > > emulation, I don't see why drift would accumulate over the long term
> > > relative to the host clock.
> > >     
> > 
> > I was measuring with ntpdate, so the drift is with respect to the ntp
> > server pool, not the host clock. But in any case, since timer interrupts
> > and reads of the hpet counter are at the mercy of the host scheduler
> > (i.e., the qemu process can be swapped out at any time during hpet read
> > or timer expiration), I'd guess there would always be some amount of
> > inaccuracy. Also, qemu checks for timer expiration (qemu_run_timers) as
> > part of a bigger loop (main_loop_wait), so the varying amounts of work
> > to do elsewhere in the loop from iteration to iteration would also
> > introduce irregular delays.
> >   
> This is exactly why hpet as the other clock emulation in qemu (pit,
> rtc, pm?) need
> to check whether their irq was really injected. Gleb sent patches for
> the rtc, pit.
> The idea is to check with the irq chip if the injected irq was really
> successful.
> 
I assume these are the patches you're referring to?
http://thread.gmane.org/gmane.comp.emulators.kvm.devel/18974/focus=18977

Looks like they were never merged. Does anyone know the history on that?
Also, HPET generates edge-triggered interrupts (as dictated by Linux and
Windows) so I'm not sure if this scheme could work for it.
> Dor
-- 
Elizabeth Kon (Beth)
IBM Linux Technology Center
Open Hypervisor Team
email: eak@us.ibm.com