From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43)
	id 1MO3Bl-000645-B8
	for qemu-devel@nongnu.org; Tue, 07 Jul 2009 01:25:57 -0400
Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43)
	id 1MO3Bf-0005xt-DM
	for qemu-devel@nongnu.org; Tue, 07 Jul 2009 01:25:55 -0400
Received: from [199.232.76.173] (port=43862 helo=monty-python.gnu.org)
	by lists.gnu.org with esmtp (Exim 4.43) id 1MO3Bf-0005xZ-9q
	for qemu-devel@nongnu.org; Tue, 07 Jul 2009 01:25:51 -0400
Received: from mx2.redhat.com ([66.187.237.31]:39739)
	by monty-python.gnu.org with esmtp (Exim 4.60)
	(envelope-from <avi@redhat.com>) id 1MO3Be-00070Y-O5
	for qemu-devel@nongnu.org; Tue, 07 Jul 2009 01:25:50 -0400
Message-ID: <4A52DBE2.8010703@redhat.com>
Date: Tue, 07 Jul 2009 08:23:46 +0300
From: Avi Kivity <avi@redhat.com>
MIME-Version: 1.0
Subject: Re: [Qemu-devel] Re: [PATCH 0/4] Machine config files
References: <20090610173803.4674.82538.stgit@wren.home>	<4A52284C.9080604@redhat.com>
	<4A523444.30002@codemonkey.ws>	<200907062339.43850.paul@codesourcery.com>
	<4A528516.4020402@codemonkey.ws>
In-Reply-To: <4A528516.4020402@codemonkey.ws>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
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: "Michael S. Tsirkin" <mst@redhat.com>, Jan Kiszka <jan.kiszka@siemens.com>, qemu-devel@nongnu.org, Markus Armbruster <armbru@redhat.com>, Gerd Hoffmann <kraxel@redhat.com>, Paul Brook <paul@codesourcery.com>

On 07/07/2009 02:13 AM, Anthony Liguori wrote:
>>
>> RAM is part of the machine config, and can be hotplugged[1], so you 
>> need at least that before you start transferring anything.
>
>
> You really don't.  The ram_load_live handler should receive RAM as it 
> comes in and maintain a growable buffer for all the independently 
> transferred regions.  A nice property of live migration is that you'll 
> get the whole region at once so something simple based on realloc() 
> will work well.
>

One nasty bit here is large page support.  We need to know memory layout 
in advance so we can migrate to appropriately allocated and aligned 
sections.

realloc()s could work, but they'd be slow (seconds) on large guests, and 
you're not guaranteed to have enough memory.

-- 
I have a truly marvellous patch that fixes the bug which this
signature is too narrow to contain.