Re: [Qemu-devel] 答复: [PATCH 0/5] mc146818rtc: fix Windows VM clock faster

[Xiao Guangrong <guangrong.xiao@gmail.com>]

On 04/13/2017 05:38 PM, Hailiang Zhang wrote:
> On 2017/4/13 17:35, Xiao Guangrong wrote:
>>
>> On 04/13/2017 05:29 PM, Hailiang Zhang wrote:
>>> On 2017/4/13 17:18, Xiao Guangrong wrote:
>>>> On 04/13/2017 05:05 PM, Zhanghailiang wrote:
>>>>> Hi,
>>>>>
>>>>> -----邮件原件-----
>>>>> 发件人: kvm-owner@vger.kernel.org [mailto:kvm-owner@vger.kernel.org]
>>>>> 代表 Xiao Guangrong
>>>>> 发送时间: 2017年4月13日 16:53
>>>>> 收件人: Paolo Bonzini; mst@redhat.com; mtosatti@redhat.com
>>>>> 抄送: qemu-devel@nongnu.org; kvm@vger.kernel.org;
>>>>> yunfangtai@tencent.com; Xiao Guangrong
>>>>> 主题: Re: [PATCH 0/5] mc146818rtc: fix Windows VM clock faster
>>>>>
>>>>>
>>>>>
>>>>> On 04/13/2017 04:39 PM, Xiao Guangrong wrote:
>>>>>> On 04/13/2017 02:37 PM, Paolo Bonzini wrote:
>>>>>>> On 12/04/2017 17:51, guangrong.xiao@gmail.com wrote:
>>>>>>>> The root cause is that the clock will be lost if the periodic
>>>>>>>> period
>>>>>>>> is changed as currently code counts the next periodic time like
>>>>>>>> this:
>>>>>>>>         next_irq_clock = (cur_clock & ~(period - 1)) + period;
>>>>>>>>
>>>>>>>> consider the case if cur_clock = 0x11FF and period = 0x100, then
>>>>>>>> the
>>>>>>>> next_irq_clock is 0x1200, however, there is only 1 clock left to
>>>>>>>> trigger the next irq. Unfortunately, Windows guests (at least
>>>>>>>> Windows7) change the period very frequently if it runs the attached
>>>>>>>> code, so that the lost clock is accumulated, the wall-time become
>>>>>>>> faster and faster
>>>>>>> Very interesting.
>>>>>>>
>>>>>> Yes, indeed.
>>>>>>
>>>>>>> However, I think that the above should be exactly how the RTC should
>>>>>>> work.  The original RTC circuit had 22 divider stages (see page
>>>>>>> 13 of
>>>>>>> the datasheet[1], at the bottom right), and the periodic interrupt
>>>>>>> taps the rising edge of one of the dividers (page 16, second
>>>>>>> paragraph).  The datasheet also never mentions a comparator being
>>>>>>> used to trigger the periodic interrupts.
>>>>>>>
>>>>>> That was my thought before, however, after more test, i am not
>>>>>> sure if
>>>>>> re-configuring RegA changes these divider stages internal...
>>>>>>
>>>>>>> Have you checked that this Windows bug doesn't happen on real
>>>>>>> hardware too?  Or is the combination of driftfix=slew and changing
>>>>>>> periods that is a problem?
>>>>>>>
>>>>>> I have two physical windows 7 machines, both of them have
>>>>>> 'useplatformclock = off' and ntp disabled, the wall time is really
>>>>>> accurate. The difference is that the physical machines are using
>>>>>> Intel
>>>>>> Q87 LPC chipset which is mc146818rtc compatible. However, on VM, the
>>>>>> issue is easily be reproduced just in ~10 mins.
>>>>>>
>>>>>> Our test mostly focus on 'driftfix=slew' and after this patchset the
>>>>>> time is accurate and stable.
>>>>>>
>>>>>> I will do the test for dropping 'slew' and see what will happen...
>>>>>>
>>>>>> Well, the time is easily observed to be faster if 'driftfix=slew' is
>>>>>> not used. :(
>>>>> You mean, it only fixes the one case which with the ' driftfix=slew '
>>>>> is used ?
>>>> No. for both.
>>>>
>>>>> We encountered this problem too, I have tried to fix it long time ago.
>>>>> https://lists.gnu.org/archive/html/qemu-devel/2016-03/msg06937.html.
>>>>> (It seems that your solution is more useful)
>>>>> But it seems that it is impossible to fix, we need to emulate the
>>>>> behaviors of real hardware,
>>>>> but we didn't find any clear description about it. And it seems that
>>>>> other virtualization platforms
>>>> That is the issue, the hardware spec does not detail how the clock is
>>>> counted when the timer interval is changed. What we can do at this time
>>>> is that speculate it from the behaviors. Current RTC is completely
>>>> unusable anyway.
>>>>
>>>>
>>>>> have this problem too:
>>>>> VMware:
>>>>> https://www.vmware.com/files/pdf/Timekeeping-In-VirtualMachines.pdf
>>>>> Heper-v:
>>>>> https://blogs.msdn.microsoft.com/virtual_pc_guy/2010/11/19/time-synchronization-in-hyper-v/
>>>>>
>>>>>
>>>> Hmm, slower clock is understandable, does really the Windows7 on hyperV
>>>> have faster clock? Did you meet it?
>>> I don't know, we didn't test it, besides, I'd like to know how long did
>>> your testcase run before
>>> you judge it is stable with 'driftfix=slew'  option? (My previous patch
>>> can't fix it completely but
>>> only narrows the gap between timer in guest and real timer.)
>> More than 12 hours.
>
> Great, I'll test and look into it ... thanks.
>

Hi Hailiang,

Does this patchset work for you? :)