From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 66D92C67871 for ; Thu, 27 Oct 2022 07:50:32 +0000 (UTC) Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1onxeL-0001jl-Dh; Thu, 27 Oct 2022 03:50:01 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1onxeJ-0001fq-SR for qemu-devel@nongnu.org; Thu, 27 Oct 2022 03:49:59 -0400 Received: from us-smtp-delivery-124.mimecast.com ([170.10.133.124]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1onxeI-0006oj-2r for qemu-devel@nongnu.org; Thu, 27 Oct 2022 03:49:59 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1666856997; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=BN7VfIUnlcWHI+M1f0Yxnws7orrNBs/KiKobJ9nDHLs=; b=dZDZVUk5nwFYm+IfnbJF2OLojCjYfFODXXs/bFOG2c0QPjbSROn1gvp4XTLZ9P3R5d/L0e oBjnxgQ07VbppUTnKZ2uXv1dhdUBero61i7SrzIr2MwXsREk3nEDD/jyedXInVSn1Msw4r VMF9vpWX8d7PJZmTVMA+s8XYlRcp6oI= Received: from mail-oi1-f200.google.com (mail-oi1-f200.google.com [209.85.167.200]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_128_GCM_SHA256) id us-mta-594-7xKihwD6ONq3nDm7pvv10w-1; Thu, 27 Oct 2022 03:49:55 -0400 X-MC-Unique: 7xKihwD6ONq3nDm7pvv10w-1 Received: by mail-oi1-f200.google.com with SMTP id bh28-20020a056808181c00b0035522358734so463300oib.10 for ; Thu, 27 Oct 2022 00:49:54 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=BN7VfIUnlcWHI+M1f0Yxnws7orrNBs/KiKobJ9nDHLs=; b=RAbJ2NtHxVilmzrLjGFuRLiqWciejl5gLIviqtNlpZqcL3e/Xn3QE8MKBlKSr0tr7U SmYYTViyISk5WIz538WGotx5iDkMTT3MsyvEIz0nNA+q5o+P5d40Um50w/6KVBysShHb Rd5IDm8sIq+KMlYAkfKlIV/c3EEGJ1+jssB4yOsrYVcH7TQZtOMvTZxXYc4Ew7ng8uQU FZ5Qhc7bkF+FzL/Jmz/+MQkiYvs7bAbeunA7OvY2DSVLhD2Slhi2RAVMoRa5r/+abaB+ spPcLkqUgr5u7Q8U4tgss3bLbXOSoksUPuVUKqa1uoMys2S+cptkpacir8rZV7Jn/VGj bSyg== X-Gm-Message-State: ACrzQf044X+0Z6aSKL2hgoUWf/q/KT8mm//F0bAMmZYInDqHZw5qiHTt GOMm8CiYMbuhh9jbnYUfMxg3Sr6maD62DvM0eeEaHPZEe6QqEOGAegRUlxyfET+1iSCkIKFoUW2 /z5xgMeZUCXVvRdTO+dX7PgBLCo9lAqY= X-Received: by 2002:a05:6808:1386:b0:359:bf47:ed55 with SMTP id c6-20020a056808138600b00359bf47ed55mr727290oiw.14.1666856994337; Thu, 27 Oct 2022 00:49:54 -0700 (PDT) X-Google-Smtp-Source: AMsMyM7IEMOfp5Jnz4mPYexuz/fz8St0GwNAxvljltNdRlmGszokvtUZdRstT4yCAy6uPAN7UB64Fxpx1LHNHOU23no= X-Received: by 2002:a05:6808:1386:b0:359:bf47:ed55 with SMTP id c6-20020a056808138600b00359bf47ed55mr727281oiw.14.1666856994054; Thu, 27 Oct 2022 00:49:54 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Konstantin Kostiuk Date: Thu, 27 Oct 2022 10:49:43 +0300 Message-ID: Subject: Re: Crash in RTC To: Paolo Bonzini , "Michael S. Tsirkin" Cc: Vadim Rozenfeld , QEMU Content-Type: multipart/alternative; boundary="00000000000005b56e05ebff63d4" Received-SPF: pass client-ip=170.10.133.124; envelope-from=kkostiuk@redhat.com; helo=us-smtp-delivery-124.mimecast.com X-Spam_score_int: -25 X-Spam_score: -2.6 X-Spam_bar: -- X-Spam_report: (-2.6 / 5.0 requ) BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.515, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: qemu-devel@nongnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: "Qemu-devel" Errors-To: qemu-devel-bounces+qemu-devel=archiver.kernel.org@nongnu.org --00000000000005b56e05ebff63d4 Content-Type: text/plain; charset="UTF-8" ping On Wed, Aug 31, 2022 at 11:33 AM Vadim Rozenfeld wrote: > Just a bit more info related to this issue. > Below is a quote from my previous conversation with Yan > > > 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. > > > > Cheers, > Vadim. > > On Wed, Aug 31, 2022 at 5:46 PM Konstantin Kostiuk > wrote: > >> CC: Vadim >> >> On Wed, Aug 31, 2022 at 10:42 AM Konstantin Kostiuk >> wrote: >> >>> ping >>> >>> On Wed, Aug 24, 2022 at 5:37 PM Konstantin Kostiuk >>> 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. >>>> >>> --00000000000005b56e05ebff63d4 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
ping

On Wed, Aug 31, 2022 at 11:33 AM Vadim Rozenfeld &= lt;vrozenfe@redhat.com> wrote= :
Just a bit more info related to this issue.
Below is a qu= ote from my previous conversation with Yan

</QU= OTE>
QEMU RTC function periodic_timer_update is calli= ng in response
to Windows HAL calls
_HalpRtcArmTim= er@16
and
_HalpRtcStop@4

= WIndows can change timer=C2=A0 frequency=C2=A0 dynamically
(some more i= nfo can be found here https://bugzilla.redhat.com/show_bug.cgi?id= =3D1610461 )
but calculation of the frequency is based on the= wallclock time (IIRC).
And if I'm not mistaken, then lost_ti= ck_policy=3Ddelay 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 r= eason for that?=C2=A0 They might try switching
to hv_stimer inste= ad of RTC.

And one more thing, the frequency of th= e timer can be adjusted by UM applications.
Some of them , like e= mulators and servers use it quite widely. It worse=C2=A0 asking them
<= div>if they are running such kinds of apps.
</QUOTE>


Cheers,
Vadim.

On Wed, Aug 31, 2022 at 5:46 PM Konstantin Kostiuk <kkostiuk@redhat.com> wrote:
CC: Vadim

On Wed, Aug 31, 2022 at 10:42 AM Konstantin Kost= iuk <kkostiuk@r= edhat.com> wrote:
ping

On Wed, Aug 24, 2022 at 5:37 PM Konstan= tin Kostiuk <kk= ostiuk@redhat.com> wrote:
Hi Michael and Paolo,

I write to y= ou as maintainers of mc146818rtc.c. I am working on bug https://bu= gzilla.redhat.com/show_bug.cgi?id=3D2054781
and reproduced it on the= current master branch.

I added some print at line 202 (before asser= t(lost_clock >=3D 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_cl= ock, cur_clock, lost_clock, current_time
54439076429968, 32, 54439076429= 936, 54439076430178, 242, 1661348768010822000
54439076430224, 512, 54439= 076429712, 54439076430188, 476, 1661348768011117000
54439076430224, 32, = 54439076430192, 54439076429884, -308, 1661348768001838000

The curren= t_time value in the last print is lower than in the previous one.
So, th= e error occurs because time has gone backward.

I think this is a pos= sible situation during time synchronization.
My question is what should = we do in this case?

Best Regards,
Konstantin Kostiuk.
<= /div>
--00000000000005b56e05ebff63d4--