From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Kdp5e-0000WH-Ao for qemu-devel@nongnu.org; Thu, 11 Sep 2008 12:32:18 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1Kdp5d-0000V5-EI for qemu-devel@nongnu.org; Thu, 11 Sep 2008 12:32:17 -0400 Received: from [199.232.76.173] (port=39427 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Kdp5d-0000Uw-9P for qemu-devel@nongnu.org; Thu, 11 Sep 2008 12:32:17 -0400 Received: from il.qumranet.com ([212.179.150.194]:34980) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1Kdp5d-0004sm-1X for qemu-devel@nongnu.org; Thu, 11 Sep 2008 12:32:17 -0400 Message-ID: <48C9480E.7050002@qumranet.com> Date: Thu, 11 Sep 2008 19:32:14 +0300 From: Avi Kivity MIME-Version: 1.0 Subject: Re: [Qemu-devel] [PATCH 0/10] Live migration for QEMU References: <1220989802-13706-1-git-send-email-aliguori@us.ibm.com> <200809111213.m8BCDHaC012607@fjmscan502.ms.jp.fujitsu.com> <48C917F3.7040507@codemonkey.ws> <20080911133046.GE16427@shareable.org> <48C92742.8000002@us.ibm.com> <48C939F6.1070006@qumranet.com> <48C945DD.4020304@codemonkey.ws> In-Reply-To: <48C945DD.4020304@codemonkey.ws> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Reply-To: qemu-devel@nongnu.org List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Anthony Liguori Cc: Chris Wright , Uri Lublin , qemu-devel@nongnu.org, kvm@vger.kernel.org Anthony Liguori wrote: >>> >>> Yes. The primary reason that hasn't been possible in the past was >>> because of how memory was migrated. The new memory migration >>> protocol happens to make it easier to let QEMU and KVM be >>> compatible. That wasn't an accident :-) >>> >> >> Well, it's still broken IMO (migration ram_addr_t rather than >> physical addresses). > > Have you thought of a solution other than make "mem" only save > physical memory and have everything else save their own memory? > Even worse, have each slot (0-640K, 1M-pci, 4GB-eom, hotplug slots, writeable option roms) be an independent save/restore entity. > That gets really funky because then everything needs live save/restore > tracking. It's quite messy. Why? they can all reuse the same code. -- error compiling committee.c: too many arguments to function