There exists a simple patch that changes the wait loop timer to use
CLOCK_MONOTONIC. See
https://github.com/portante/qemu/commit/35c92daa9784882153c6d8b0e15e8c8f181d6e8a
.
-peter
On Tue, Mar 27, 2012 at 12:00 PM, Jan Kiszka <jan.kis...@siemens.com> wrote:
> On 2012-03-27 17:52, Paolo Bonzini wrote:
> > Il 27/03/2012 17:08, Jan Kiszka ha scritto:
> >>>> +#if defined(__sun__)
> >>>> + if (timer_create(CLOCK_HIGHRES, &ev, &host_timer)) {
> >>>> +#else
> >>>> if (timer_create(CLOCK_REALTIME, &ev, &host_timer)) {
> >>>> +#endif
> >>>
> >>> This should be #ifdef CLOCK_HIGHRES.
> >>
> >> Are we sure about this is and will remain equivalent and correct?
> >>
> >> Also, I found some man page that says CLOCK_HIGHRES is non-adjustable
> >> while CLOCK_REALTIME is. That should make a difference in QEMU.
> >
> > Right, that's why I CCed you but then I forgot to ask the question.
> >
> > Does QEMU rely on CLOCK_REALTIME when "-rtc clock=host" is in use? A
> > monotonic clock would work better when CLOCK_REALTIME jumps backwards
> > (DST->solar). If the jump goes unnoticed, the alarm timer would have no
> > timeout for an hour or so.
> >
> > Of course the opposite is true when going from solar time to DST; you
> > move the realtime clock one hour forward and, with CLOCK_MONOTONIC, a
> > host_clock timer to trigger an hour too late.
>
> But the latter would be fixed up when we actually check for expired
> timers against the proper clocks. Hmm, I'm not sure anymore if we really
> need CLOCK_REALTIME for the timer here. This also has no telling
> history. Maybe the contributor of dynticks just didn't think about this
> aspect of REALTIME vs. MONOTONIC.
>
> Jan
>
> --
> Siemens AG, Corporate Technology, CT T DE IT 1
> Corporate Competence Center Embedded Linux
>
>
