From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43)
	id 1MvpLC-0006Jb-8g
	for qemu-devel@nongnu.org; Thu, 08 Oct 2009 05:31:18 -0400
Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43)
	id 1MvpL7-0006IS-GC
	for qemu-devel@nongnu.org; Thu, 08 Oct 2009 05:31:17 -0400
Received: from [199.232.76.173] (port=45063 helo=monty-python.gnu.org)
	by lists.gnu.org with esmtp (Exim 4.43) id 1MvpL7-0006IP-8g
	for qemu-devel@nongnu.org; Thu, 08 Oct 2009 05:31:13 -0400
Received: from thoth.sbs.de ([192.35.17.2]:16397)
	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 1MvpL6-0001i5-FS
	for qemu-devel@nongnu.org; Thu, 08 Oct 2009 05:31:12 -0400
Message-ID: <4ACDB15D.3070607@siemens.com>
Date: Thu, 08 Oct 2009 11:31:09 +0200
From: Jan Kiszka <jan.kiszka@siemens.com>
MIME-Version: 1.0
References: <m3pr8yna7s.fsf@neno.mitica>
In-Reply-To: <m3pr8yna7s.fsf@neno.mitica>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Subject: [Qemu-devel] Re: Host clock broke loadvm
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: Juan Quintela <quintela@redhat.com>
Cc: "qemu-devel@nongnu.org" <qemu-devel@nongnu.org>

Juan Quintela wrote:
> Hi Jan
> 
> Today I found that I am not able to load anymore old saved images (old
> means more than 2 days old).  Problem is with host clock.
> 
> I need to run qemu with -rtc clock=vm, and then things cames to work
> again.
> 
> My suspicion is that the saved timers are based from cpu_clock_offset,
> and when we run now with host_clock, that value don't exist.
> 
> If I don't use -rtc clock=vm, machines will come eventually to life, but
> it will take several minutes.

That makes sense as you cannot simply migrate timers between clocks (in
this case, you would have to patch the timeout value of the rtc timer
after resume).

> 
> Anthony asked to change pc-11 definition to use vm clock.  What do you
> think?

Definitely makes sense, also for other reasons unrelated to save/restore.

>  Any other good idea to make a machine saved with clock=vm to
> load with clock=host.
> 
> I tried the trial:
> 
> if (cpu_clock_offset != 0)
>    rtc_clock = vm_clock;
> 
> after loading an image, but that didn't fixed the problem (I didn't
> investigate more).
> 
> Do you have a plan to go from here?

I would say, first go for clock=vm for pc-11. Until someone comes up
with a good reason to migrate from clock=vm to clock=host, don't try to
be smarter than required.

Jan

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