From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43)
	id 1Mm1tw-0000sU-A0
	for qemu-devel@nongnu.org; Fri, 11 Sep 2009 04:54:40 -0400
Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43)
	id 1Mm1tr-0000sI-L3
	for qemu-devel@nongnu.org; Fri, 11 Sep 2009 04:54:39 -0400
Received: from [199.232.76.173] (port=33455 helo=monty-python.gnu.org)
	by lists.gnu.org with esmtp (Exim 4.43) id 1Mm1tr-0000sF-I5
	for qemu-devel@nongnu.org; Fri, 11 Sep 2009 04:54:35 -0400
Received: from david.siemens.de ([192.35.17.14]:16386)
	by monty-python.gnu.org with esmtps
	(TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60)
	(envelope-from <jan.kiszka@siemens.com>) id 1Mm1tr-0004kL-15
	for qemu-devel@nongnu.org; Fri, 11 Sep 2009 04:54:35 -0400
Message-ID: <4AAA1059.9060505@siemens.com>
Date: Fri, 11 Sep 2009 10:54:49 +0200
From: Jan Kiszka <jan.kiszka@siemens.com>
MIME-Version: 1.0
Subject: Re: [Qemu-devel] Re: [PATCH 0/5] Refactor and enhance RTC
	configuration
References: <20090909222333.GA19385@shareable.org>
In-Reply-To: <20090909222333.GA19385@shareable.org>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
List-Id: qemu-devel.nongnu.org
List-Unsubscribe: <http://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.gnu.org/pipermail/qemu-devel>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <http://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: Jamie Lokier <jamie@shareable.org>
Cc: Blue Swirl <blauwirbel@gmail.com>, Anthony Liguori <aliguori@us.ibm.com>, Dor Laor <dlaor@redhat.com>, Glauber Costa <glommer@redhat.com>, "qemu-devel@nongnu.org" <qemu-devel@nongnu.org>

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.

> 
> Will the -startdate functionality be maintained with the RTC changes?

Yes, just like -localtime, this will still be supported of course.

Jan

-- 
Siemens AG, Corporate Technology, CT SE 2
Corporate Competence Center Embedded Linux