Re: [Qemu-devel] Re: [PATCH] re-set rtc date on reset handler

[Dor Laor]

On 09/08/2009 08:00 PM, Jan Kiszka wrote:
> Jan Kiszka wrote:
> > Jan Kiszka wrote:
> > > Blue Swirl wrote:
> > > > On Tue, Sep 1, 2009 at 7:22 PM, Glauber Costa<address@hidden>  wrote:
> > > > > guests without a stable timesource such as kvm-clock will grab the wallclock
> > > > > from our rtc chip. However, we only sync the date when we first launch qemu.
> > > > > If a guest goes through a series of reboot cycles, it will slowly see time
> > > > > getting far behind the host.
> > > > >
> > > > > The proposal of this patch is to set the date to host clock again in the reset
> > > > > handler. With this patch, I see a Fedora guest keeping its clock in sync upon
> > > > > an ulimited number of reboots.
> > > > A different approach is used in m48t59.c: the guest clock is generated
> > > > directly from host clock without any timers and only a fixed offset
> > > > (to account for time when guest was stopped) is added, so the clock
> > > > will always in sync.
> > > Ah, that looks like a useful approach! We currently face the issue of
> > > vRTC drifting away from the host time (as the latter is tuned by NTP).
> > >
> > > Do you or anyone else know if switching the PC RTC over to the scheme
> > > used in the m48t59 may have some downsides? If not, I would happily hack
> > > up a patch ASAP and suggest it for mainline.
> >
> > Clearly, one downside is that a jumping host time will cause the RTC to
> > jump as well. However, there might by setups where this does not happen,
> > so optionally switching the RTC over rt_clock seems like a reasonable
> > feature to me.
> >
> > What about consolidating -localtime, -starttime and -rtc-td-hack at this
> > chance? Something like
> >
> >   -rtc base=utc|localtime|date,clock=vm|rt
>
> + ,td-hack=on|off
>
> of course. Or let's call it "drift-hack".

btw: this is not a hack, its virtualization support for rtc.
It should be the default when qemu runs along with kvm.

> > with 'date' specifying the base as in -starttime. 'clock' would then
> > allow to drive the RTC via the host's CLOCK_REALTIME (with all its pros
> > and cons).
> >
> > Jan
>
> Jan