qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Jan Kiszka
Subject: Re: [Qemu-devel] Re: [PATCH] re-set rtc date on reset handler
Date: Wed, 09 Sep 2009 14:57:00 +0200
User-agent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); de; rv:1.8.1.12) Gecko/20080226 SUSE/2.0.0.12-1.1 Thunderbird/2.0.0.12 Mnenhy/0.7.5.666

Dor Laor wrote:
> 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.

OK, will call it 'drift-fix'. But enabling it by default in kvm mode
should be filed as a separate patch on top of my queue (which will
appear soon).

Jan

-- 
Siemens AG, Corporate Technology, CT SE 2
Corporate Competence Center Embedded Linux




reply via email to

[Prev in Thread] Current Thread [Next in Thread]