From: "贾庆彤 via" <qemu-devel@nongnu.org>
To: <qemu-devel@nongnu.org>
Subject: RTC time could run slow 3s than host time when clock=vm & base=UTC
Date: Sat, 21 Sep 2024 19:33:31 +0800 [thread overview]
Message-ID: <eba4b2cf-cf64-4237-aaf6-8aa521c77007@huawei.com> (raw)
When start qemu with -rtc base=utc,clock=vm, sometime guest time can
slower 3s than host.
There's no problem (also didn't be noticed) as we often start ntp
service, who will adjust our system time.
But let's talk about if we havn't enable NTP service(for example system
just booted)
After inspect into the code, i found that there are two problem we
should think about:
1) The RTC time accuracy problem
1. in the call chains
rtc_realizefn->rtc_set_date_from_host->qemu_get_timedate->qemu_ref_timedate,
the qemu_clock_get_ms(clock) / 1000 will lost ~0.999s at max.
2. In the call chains cmos_ioport_read->rtc_update_time, the guest_sec =
guest_nsec / NANOSECONDS_PER_SECOND
will also lost ~0.999s at max.
3. after this[1] merged, in configure_rtc, the rtc_ref_start_datetime =
qemu_clock_get_ms(QEMU_CLOCK_HOST) / 1000
will also lost ~0.999s at max.
Therefore, total about 3s the guest time will behind the host.
So what precision should we offer? the RTC Hardware's precision is
second(that means the smallest step is 1 second,
not the accurate like time error about 8.6 to 1.7 seconds per day),
2)The ref start datetime
After this[1] merged, which intend to solve the -rtc
base=DATETIME,clock=vm's problem ("It restores determinism
of guest execution when used with clock=vm and specified base value.").
"-rtc base=utc,clock=vm"'s ref start date time changed from the host
time of the current executing code to
the const time of executing configure_rtc(rtc_ref_start_datetime =
qemu_clock_get_ms(QEMU_CLOCK_HOST) / 1000;).
This will add additional time(current approx. 0.4s or other, depend on
code executing time and how many class_init
executed etc.),which start from configure_rtc to rtc device init, into
guest time.
Hence, should we try to split -rtc base=utc,clock=vm's ref start date
time to the original current host time
qemu_clock_get_ms(QEMU_CLOCK_HOST),not the time(rtc_ref_start_datetime)
save in configure_rtc,
to achieve more accurate time?(or other better method)
[1] https://lists.gnu.org/archive/html/qemu-devel/2018-10/msg03577.html
next reply other threads:[~2024-09-21 13:13 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-09-21 11:33 贾庆彤 via [this message]
2024-09-28 10:47 ` RTC time could run slow 3s than host time when clock=vm & base=UTC Zenghui Yu via
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=eba4b2cf-cf64-4237-aaf6-8aa521c77007@huawei.com \
--to=qemu-devel@nongnu.org \
--cc=jiaqingtong@huawei.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).