qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] Re: [PATCH 0/5] Refactor and enhance RTC configuration


From: Dor Laor
Subject: Re: [Qemu-devel] Re: [PATCH 0/5] Refactor and enhance RTC configuration
Date: Sun, 13 Sep 2009 18:08:57 +0300
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.1) Gecko/20090814 Fedora/3.0-2.6.b3.fc11 Lightning/1.0pre Thunderbird/3.0b3 ThunderBrowse/3.2.6.4

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






reply via email to

[Prev in Thread] Current Thread [Next in Thread]