From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MO2p9-00070Z-Vm for qemu-devel@nongnu.org; Tue, 07 Jul 2009 01:02:36 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MO2p4-0006ze-P9 for qemu-devel@nongnu.org; Tue, 07 Jul 2009 01:02:34 -0400 Received: from [199.232.76.173] (port=49603 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MO2p4-0006zQ-IQ for qemu-devel@nongnu.org; Tue, 07 Jul 2009 01:02:30 -0400 Received: from mx2.redhat.com ([66.187.237.31]:43502) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1MO2p3-0003qb-Td for qemu-devel@nongnu.org; Tue, 07 Jul 2009 01:02:30 -0400 Message-ID: <4A52D674.4020505@redhat.com> Date: Tue, 07 Jul 2009 08:00:36 +0300 From: Avi Kivity 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: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Anthony Liguori Cc: "Michael S. Tsirkin" , Jan Kiszka , Markus Armbruster , qemu-devel@nongnu.org, Gerd Hoffmann , Paul Brook On 07/07/2009 02:13 AM, Anthony Liguori wrote: > Paul Brook wrote: >>> Most importantly, machine config should not be sent until non-live >>> migration kicks in. At this point, the device tree is stable because >>> the guest isn't running. The device tree should be the first section >>> saved for non-live migration. >> >> 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. > It's doable but it looks like we're implementing things twice. If we have memory/vga hotplug, then we already support all of this at the hotplug level. All we need to do is send the hotplug command over. It occured to me that except for RAM we can migrate using the monitor protocol. Start by serializing the qdev tree into an object and create the target machine from that. Additional hotplug commands during the migration are simply forwarded to the other side. -- I have a truly marvellous patch that fixes the bug which this signature is too narrow to contain.