From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from eggs.gnu.org ([208.118.235.92]:50667)
	by lists.gnu.org with esmtp (Exim 4.71)
	(envelope-from <benh@kernel.crashing.org>) id 1Sh6LC-0003qL-4j
	for qemu-devel@nongnu.org; Tue, 19 Jun 2012 17:52:04 -0400
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
	(envelope-from <benh@kernel.crashing.org>) id 1Sh6LA-0005Hq-0Y
	for qemu-devel@nongnu.org; Tue, 19 Jun 2012 17:52:01 -0400
Received: from gate.crashing.org ([63.228.1.57]:44340)
	by eggs.gnu.org with esmtp (Exim 4.71)
	(envelope-from <benh@kernel.crashing.org>) id 1Sh6L9-0005HQ-Nd
	for qemu-devel@nongnu.org; Tue, 19 Jun 2012 17:51:59 -0400
Message-ID: <1340142715.28143.41.camel@pasglop>
From: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Date: Wed, 20 Jun 2012 07:51:55 +1000
In-Reply-To: <99D704E3-384D-42C6-997C-379D850AC347@suse.de>
References: <1339239192.24838.84.camel@pasglop>
	<1339241642.24838.92.camel@pasglop>
	<5DD2FF44-F27E-49C4-AF2C-2EF95341DF6E@suse.de>
	<87lijjjqk5.fsf@elfo.mitica> <1340137841.28143.34.camel@pasglop>
	<C8F69AD1-955B-4E27-99FB-D3E494D71898@suse.de>
	<1340140421.28143.39.camel@pasglop>
	<99D704E3-384D-42C6-997C-379D850AC347@suse.de>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0
Subject: Re: [Qemu-devel] vm state save/restore question
List-Id: <qemu-devel.nongnu.org>
List-Unsubscribe: <https://lists.nongnu.org/mailman/options/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: <https://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: Alexander Graf <agraf@suse.de>
Cc: "qemu-devel@nongnu.org Developers" <qemu-devel@nongnu.org>, "quintela@redhat.com" <quintela@redhat.com>

On Tue, 2012-06-19 at 23:48 +0200, Alexander Graf wrote:
> > We could keep track manually maybe using some kind of dirty bitmap of
> > changes to the hash table but that would add overhead to things like
> > H_ENTER.
> 
> Only during migration, right?

True. It will be an "interesting" user/kernel API tho ... I'll give it more thoughts.

I need to understand better how do that vs. qemu save/restore though. IE. That means
we can't just save the hash as a bulk and reload it, but we'd have to save bits of
it at a time or something like that no ? Or do we save it once, then save the diff
at the end ?

Cheers,
Ben.