Re: [Qemu-devel] [PATCH] Timer/clock for Linux

[Jamie Lokier]

Fabrice Bellard wrote:
> Jamie Lokier wrote:
> >Fabrice Bellard wrote:
> >
> >>Can other people confirm that it is better to always use /dev/rtc on 
> >>Linux ? Is there a way to get the real resolution of the host timer ?
> >
> >
> >Yes, on recent Linux kernels you can do
> >clock_getres(CLOCK_MONOTONIC,&ts) [or CLOCK_REALTIME], and it will
> >return the length of a timer tick.  On my kernel it's 4.00025 ms.  On
> >other x86 kernels it can be ~10ms or ~1ms.
> >
> >Also the recent Linux kernels (more recent) offer "high-resolution
> >timers"; you can guess what that means.  They should be more accurate
> >than /dev/rtc when they're available, because they reprogram the timer
> >chip, though I have never tried them.  I'd guess that kernels
> >featuring them would return a small value from clock_getres().
> 
> Using clock_getres() seems a good idea if I can test that it is 
> supported. If it is not supported then /dev/rtc will be used in any case.

You'll need to check for -lrt, something like this:

    AC_SEARCH_LIBS([clock_getres], [rt posix4])

> >It's unfortunate that even on kernels where the kernel tick time is
> >1ms, setitimer() will cost you a 2ms delay.  But: why should that make
> >Windows run slower?  Doesn't qemu read the kernel clock to determine
> >that the guest is due approx. 2 timer interrupts for each host wakeup?
> >Naturally you can't let that count increase indefinitely, if the
> >emulator is too slow to run the guest at full speed, but it might be
> >an idea to count up to a small number, so that short pauses in host
> >kernel scheduling won't cause a guest to lose time.
> 
> QEMU reads the clock at each host wakeup, but it cannot compensate if 
> the guest OS requires a higher frequency than the host timer frequency. 
> Having a 1 ms period is definitively better to be able to run a wide 
> range of guest OSes.

I was thinking that if the host is woken later than it intended
(e.g. after 2ms with setitimer; could be any amount with any syscall
due to other scheduling delays), then it could fake the timer chip
time it presents to the guest for a short while as if there wasn't
really a timing gap, effectively delaying the faked clock for that
gap, and then running the faked clock faster than normal to catch up
with real time.  A control loop would ensure the amount of adjustment
stays small, converting to slippage if that's not possible.  In this
way a guest would get 1000Hz interrupts (if that's what it wants), or
any other frequency.  It would also read the values it's expecting
from the emulated timer chip as if there was no host scheduling gap,
so the guest's timing logic would function properly, counting ticks,
timing times, and still tracking real clock time.

-- Jamie