From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from [140.186.70.92] (port=44585 helo=eggs.gnu.org)
	by lists.gnu.org with esmtp (Exim 4.43) id 1Q3aHe-0003Et-0F
	for qemu-devel@nongnu.org; Sat, 26 Mar 2011 16:40:30 -0400
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
	(envelope-from <ck@iseclab.org>) id 1Q3aHd-00032t-3j
	for qemu-devel@nongnu.org; Sat, 26 Mar 2011 16:40:29 -0400
Received: from mail.seclab.tuwien.ac.at ([128.130.60.29]:59533)
	by eggs.gnu.org with esmtp (Exim 4.71)
	(envelope-from <ck@iseclab.org>) id 1Q3aHc-00031a-TU
	for qemu-devel@nongnu.org; Sat, 26 Mar 2011 16:40:29 -0400
Received: from ckol-mob.localnet (c-67-160-116-62.hsd1.wa.comcast.net
	[67.160.116.62])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	by mail.seclab.tuwien.ac.at (Postfix) with ESMTPSA id 996D72FC45
	for <qemu-devel@nongnu.org>; Sat, 26 Mar 2011 21:40:04 +0100 (CET)
From: Clemens Kolbitsch <ck@iseclab.org>
Date: Fri, 18 Mar 2011 13:39:33 -0700
MIME-Version: 1.0
Content-Type: Text/Plain;
  charset="us-ascii"
Content-Transfer-Encoding: 7bit
Message-Id: <201103181339.33709.ck@iseclab.org>
Subject: [Qemu-devel] Relative/Absolute timing snapshot problem
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.nongnu.org/archive/html/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: qemu-devel@nongnu.org

Hi list,

strange situation: When I create a snapshot using Qemu 0.14.0 stable, 
everything works smoothly and resuming the CPU takes about 1-2 seconds. If I 
don't use the snapshot file for some time, the time it takes to resume grows 
by 2-3 seconds per day. At the moment, I'm looking at a snapshot file from 
last week and it takes nearly 30 seconds to load.

Funny thing about it: if I turn my system time back to the date when the 
snapshot was created (or before that), resuming CPU works within the expected 
1-2 seconds. I have _very briefly_ looked into it and it seems like Qemu 
spends an aweful long amount of time catching up with timer execution -- is it 
possible that these are stored using absolute time instead of relative timing?

I am using qcow2 file format, because I absolutely rely on CPU-snapshots and 
support for base-files. I have read here and there that it is more or less 
broken (or at least very slow), but with the correct cache-options it works 
for me (except for this bug, of course).

Has anyone encountered this or should I start looking into it (although I have 
some experience with the core source, I'm not very experienced with the 
snapshotting code).

Thanks,
Clemens