From mboxrd@z Thu Jan 1 00:00:00 1970 From: Avi Kivity Subject: Re: [Qemu-devel] [PATCH 0/10] Live migration for QEMU Date: Thu, 11 Sep 2008 19:32:14 +0300 Message-ID: <48C9480E.7050002@qumranet.com> 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> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: qemu-devel@nongnu.org, Jamie Lokier , Chris Wright , Uri Lublin , kvm@vger.kernel.org To: Anthony Liguori Return-path: Received: from il.qumranet.com ([212.179.150.194]:34977 "EHLO il.qumranet.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751676AbYIKQcQ (ORCPT ); Thu, 11 Sep 2008 12:32:16 -0400 In-Reply-To: <48C945DD.4020304@codemonkey.ws> Sender: kvm-owner@vger.kernel.org List-ID: 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