[Top][All Lists]

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

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

From: Paolo Bonzini
Subject: Re: [Qemu-devel] [PATCH 0/5] mc146818rtc: fix Windows VM clock faster
Date: Fri, 14 Apr 2017 13:09:16 +0800
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0

On 13/04/2017 16:52, Xiao Guangrong wrote:
> On 04/13/2017 04:39 PM, Xiao Guangrong wrote:
>> On 04/13/2017 02:37 PM, Paolo Bonzini wrote:
>>> 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...

It's unlikely because there is a separate divider reset command.  But
Hailiang found the same problem, and Bochs does the same implementation
as you.

It's even possible (not sure how likely) that the original MC146818 RTC
had the bug, but recent Super I/O chips fixed it to work around the
problem with Windows.



>>> 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. :(

reply via email to

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