From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Jt7DU-00005O-Rn for qemu-devel@nongnu.org; Mon, 05 May 2008 16:23:20 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1Jt7DT-0008Vq-OI for qemu-devel@nongnu.org; Mon, 05 May 2008 16:23:20 -0400 Received: from [199.232.76.173] (port=34325 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Jt7DT-0008Vh-Ks for qemu-devel@nongnu.org; Mon, 05 May 2008 16:23:19 -0400 Received: from py-out-1112.google.com ([64.233.166.176]) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1Jt7DS-0007YQ-Tv for qemu-devel@nongnu.org; Mon, 05 May 2008 16:23:19 -0400 Received: by py-out-1112.google.com with SMTP id u52so1606304pyb.10 for ; Mon, 05 May 2008 13:23:15 -0700 (PDT) Message-ID: <481F6CAF.6060308@codemonkey.ws> Date: Mon, 05 May 2008 15:23:11 -0500 From: Anthony Liguori 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> In-Reply-To: <20080501084833.GA21769@karma.qumranet.com> 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: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Dan Kenigsberg Cc: qemu-devel@nongnu.org Dan Kenigsberg wrote: > On Sun, Apr 27, 2008 at 11:58:17AM -0500, Anthony Liguori wrote: > >> Dan Kenigsberg wrote: >> >>> Real PC lets its user set the real-time-clock and store it on CMOS, >>> which advances the clock even when the PC is offline. >>> >>> These patches will allow doing the same with VM: >>> - Before shutting a VM down, use the monitor's info timeoffset to see >>> how much (in seconds) does the rtc differ from the host clock. >>> - Store this offset somewhere. >>> - Use it next time with -startdate now+offset. >>> >>> Please tell me what do you think of it. >>> >>> >> I think a more general mechanism that stored nvram in a file would be >> interesting. Something like like -nvram file.ram. This also allows a >> guest to determine it's initial boot device and for that setting to >> persist. >> > > 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. Regards, Anthony Liguori > Do you suggest to set up a mechanism (in parallel to savevm/loadvm) > where each device with non-volatile memory could register to? Probably, > in most devices the SaveStateHandler could play the role of > SaveNVStateHandler, but some would have to do something else. This would > make the file.ram different than a memory dump. > > Regards, > > Dan > >