On 04/14/2017 01:09 PM, Paolo Bonzini wrote:
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 div
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 dat
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.x...@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:
On 04/13/2017 02:37 PM, Paolo Bonzini wrote:
On 12/04/2017 17:51, guangrong.x...@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)) + pe
On 12/04/2017 17:51, guangrong.x...@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 =
From: Xiao Guangrong
We noticed that the clock on some windows VMs, e.g, Window7 and window8
is really faster and the issue can be easily reproduced by staring the
VM with '-rtc base=localtime,clock=vm,driftfix=slew -no-hpet' and
running attached code in the guest
The root cause is that the clo
