ping On Wed, Aug 31, 2022 at 11:33 AM Vadim Rozenfeld <vroze...@redhat.com> wrote:
> Just a bit more info related to this issue. > Below is a quote from my previous conversation with Yan > > </QUOTE> > QEMU RTC function periodic_timer_update is calling in response > to Windows HAL calls > _HalpRtcArmTimer@16 > and > _HalpRtcStop@4 > > WIndows can change timer frequency dynamically > (some more info can be found here > https://bugzilla.redhat.com/show_bug.cgi?id=1610461 ) > but calculation of the frequency is based on the wallclock time (IIRC). > And if I'm not mistaken, then lost_tick_policy=delay can lead to the > wallclock time delay, > which in my understanding can lead to the incorrect frequency calculation. > > Another interesting thing is that they don't use Hyper-V enlightenments at > all. > Do you know if there is any particular reason for that? They might try > switching > to hv_stimer instead of RTC. > > And one more thing, the frequency of the timer can be adjusted by UM > applications. > Some of them , like emulators and servers use it quite widely. It worse > asking them > if they are running such kinds of apps. > </QUOTE> > > > Cheers, > Vadim. > > On Wed, Aug 31, 2022 at 5:46 PM Konstantin Kostiuk <kkost...@redhat.com> > wrote: > >> CC: Vadim >> >> On Wed, Aug 31, 2022 at 10:42 AM Konstantin Kostiuk <kkost...@redhat.com> >> wrote: >> >>> ping >>> >>> On Wed, Aug 24, 2022 at 5:37 PM Konstantin Kostiuk <kkost...@redhat.com> >>> wrote: >>> >>>> Hi Michael and Paolo, >>>> >>>> I write to you as maintainers of mc146818rtc.c. I am working on bug >>>> https://bugzilla.redhat.com/show_bug.cgi?id=2054781 >>>> and reproduced it on the current master branch. >>>> >>>> I added some print at line 202 (before assert(lost_clock >= 0), >>>> https://gitlab.com/qemu-project/qemu/-/blob/master/hw/rtc/mc146818rtc.c#L202) >>>> and got the following values: >>>> >>>> next_periodic_clock, old_period, last_periodic_clock, cur_clock, >>>> lost_clock, current_time >>>> 54439076429968, 32, 54439076429936, 54439076430178, 242, >>>> 1661348768010822000 >>>> 54439076430224, 512, 54439076429712, 54439076430188, 476, >>>> 1661348768011117000 >>>> 54439076430224, 32, 54439076430192, 54439076429884, -308, >>>> 1661348768001838000 >>>> >>>> The current_time value in the last print is lower than in the previous >>>> one. >>>> So, the error occurs because time has gone backward. >>>> >>>> I think this is a possible situation during time synchronization. >>>> My question is what should we do in this case? >>>> >>>> Best Regards, >>>> Konstantin Kostiuk. >>>> >>>
