From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43)
	id 1Jt80e-0001Sp-JD
	for qemu-devel@nongnu.org; Mon, 05 May 2008 17:14:08 -0400
Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43)
	id 1Jt80d-0001Sd-2a
	for qemu-devel@nongnu.org; Mon, 05 May 2008 17:14:07 -0400
Received: from [199.232.76.173] (port=35289 helo=monty-python.gnu.org)
	by lists.gnu.org with esmtp (Exim 4.43) id 1Jt80c-0001Sa-Tp
	for qemu-devel@nongnu.org; Mon, 05 May 2008 17:14:06 -0400
Received: from bzq-179-150-194.static.bezeqint.net ([212.179.150.194]
	helo=il.qumranet.com) by monty-python.gnu.org with esmtp (Exim 4.60)
	(envelope-from <avi@qumranet.com>) id 1Jt80c-0007Wr-H1
	for qemu-devel@nongnu.org; Mon, 05 May 2008 17:14:06 -0400
Message-ID: <481F7896.1000409@qumranet.com>
Date: Tue, 06 May 2008 00:13:58 +0300
From: Avi Kivity <avi@qumranet.com>
MIME-Version: 1.0
Subject: Re: [Qemu-devel] [Patch] [kinda-resend] persistent real-time-clock
References: <20080427154501.GA20547@karma.qumranet.com>	<4814B0A9.7090601@codemonkey.ws>	<20080501084833.GA21769@karma.qumranet.com>
	<481F6CAF.6060308@codemonkey.ws>
In-Reply-To: <481F6CAF.6060308@codemonkey.ws>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Reply-To: qemu-devel@nongnu.org
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: Anthony Liguori <anthony@codemonkey.ws>
Cc: Dan Kenigsberg <danken@qumranet.com>, qemu-devel@nongnu.org

Anthony Liguori wrote:
>>
>> I'm not sure I understood what you suggest here.
>>
>> Plainly storing the rtc state on file is not enough, as unlike with real
>> hardware, nothing will advance it when the power is off.
>>   
>
> If you made the CMOS non-volatile, what you would store in the CMOS is 
> the clock-offset, not the actual clock time.  Then when the VM started 
> up again, it would Just Work.
>
> You would probably have to use a different location in CMOS to store 
> the offset than what the guest relies on to read the current time.

Under this, the CMOS would not be read by the guest at any time.  So why 
store the CMOS at all?  Store the offset somewhere and avoid the CMOS 
(gaining the ability to work on targets without nonvolatile memory).

It's config file territory, not CMOS.

-- 
Do not meddle in the internals of kernels, for they are subtle and quick to panic.