From: Dor Laor <dlaor@redhat.com>
To: Jan Kiszka <jan.kiszka@siemens.com>
Cc: Blue Swirl <blauwirbel@gmail.com>,
Anthony Liguori <aliguori@us.ibm.com>,
Glauber Costa <glommer@redhat.com>,
"qemu-devel@nongnu.org" <qemu-devel@nongnu.org>
Subject: Re: [Qemu-devel] Re: [PATCH 0/5] Refactor and enhance RTC configuration
Date: Sun, 13 Sep 2009 18:08:57 +0300 [thread overview]
Message-ID: <4AAD0B09.8040903@redhat.com> (raw)
In-Reply-To: <4AAA1059.9060505@siemens.com>
On 09/11/2009 11:54 AM, Jan Kiszka wrote:
> Jamie Lokier wrote:
>> Anthony Liguori wrote:
>>>> Besides the interface thing, I'm also interesting in comments on the
>>>> other core idea, the selectable RTC base clock. Do we want this knob? Do
>>>> we want host_clock unconditionally? Or should the other RTC that
>>>> currently use the host time already also gain vm_clock support over the
>>>> time?
>>>>
>>> Hard to say. Doesn't the rtc keep track of wallclock time even on power
>>> off? I think using host_clock unconditionally does actually make sense.
>>
>> Sometimes it's useful to offset the emulated clock for one reason or
>> another, hence the -startdate options. But having it run at the
>> correct speed is usually useful :-)
>
> Indeed.
>
>>
>> Also, sometimes (due to licenses with wallclock limits) it's useful
>> for a guest to not see much time pass when the guest is powered off,
>> although it still needs to be positive.
>
> I'm not sure if this is a common use case. And it currently only seems
> to be support by very few RTCs, the MC146818 being the most prominent one.
>
> I'm now a fan of converting the latter to the common scheme of using the
> host's system time (here via host_clock) and watch out for the need of
> adding -rtc clock=vm.
I'm in favor of sticking to clock=vm as a default.
Most chances that the guest will have internet connect and the host (ala
rom hypervisor) won't have.
Furthermore, if the guest and the host are running ntp it might cause
spurious ntp updates by the guest. Also on migration, you need to make
sure that both src and dst are synchronized. When using clock=vm there
is no such need.
Is the only case that clock=host is preferred is when the guest does not
run ntp while the host does?
>
>>
>> Will the -startdate functionality be maintained with the RTC changes?
>
> Yes, just like -localtime, this will still be supported of course.
btw: -startdate is good when the host and the guest use different TZs.
>
> Jan
>
next prev parent reply other threads:[~2009-09-13 15:09 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-09-09 15:11 [Qemu-devel] [PATCH 0/5] Refactor and enhance RTC configuration Jan Kiszka
2009-09-09 15:11 ` [Qemu-devel] [PATCH 2/5] win32: Drop dead dyntick timer code Jan Kiszka
2009-09-09 15:11 ` [Qemu-devel] [PATCH 4/5] Refactor RTC command line switches Jan Kiszka
2009-09-09 15:11 ` [Qemu-devel] [PATCH 1/5] Rename QEMU_TIMER_* to QEMU_CLOCK_* Jan Kiszka
2009-09-09 15:11 ` [Qemu-devel] [PATCH 3/5] Introduce QEMU_CLOCK_HOST Jan Kiszka
2009-09-09 15:11 ` [Qemu-devel] [PATCH 5/5] Enable host-clock-based RTC Jan Kiszka
2009-09-09 15:40 ` [Qemu-devel] Re: [PATCH 0/5] Refactor and enhance RTC configuration Anthony Liguori
2009-09-09 16:24 ` Jan Kiszka
2009-09-09 16:41 ` Jan Kiszka
2009-09-09 18:03 ` Markus Armbruster
2009-09-09 17:59 ` Anthony Liguori
2009-09-09 20:00 ` Jan Kiszka
2009-09-09 20:18 ` Anthony Liguori
2009-09-09 22:23 ` Jamie Lokier
2009-09-11 8:54 ` Jan Kiszka
2009-09-13 15:08 ` Dor Laor [this message]
2009-09-13 15:37 ` Jan Kiszka
2009-09-14 13:36 ` Anthony Liguori
2009-09-14 15:40 ` Jan Kiszka
2009-09-09 17:59 ` Markus Armbruster
2009-09-10 10:41 ` Gerd Hoffmann
2009-09-09 17:33 ` Blue Swirl
2009-09-09 19:13 ` Jan Kiszka
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=4AAD0B09.8040903@redhat.com \
--to=dlaor@redhat.com \
--cc=aliguori@us.ibm.com \
--cc=blauwirbel@gmail.com \
--cc=glommer@redhat.com \
--cc=jan.kiszka@siemens.com \
--cc=qemu-devel@nongnu.org \
/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).