From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1LbuUR-00041f-UP for qemu-devel@nongnu.org; Tue, 24 Feb 2009 05:26:15 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1LbuUQ-00041M-64 for qemu-devel@nongnu.org; Tue, 24 Feb 2009 05:26:15 -0500 Received: from [199.232.76.173] (port=35586 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1LbuUP-00041J-TS for qemu-devel@nongnu.org; Tue, 24 Feb 2009 05:26:13 -0500 Received: from mx2.redhat.com ([66.187.237.31]:58995) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1LbuUP-0001oj-GM for qemu-devel@nongnu.org; Tue, 24 Feb 2009 05:26:13 -0500 Message-ID: <49A3C95C.80205@redhat.com> Date: Tue, 24 Feb 2009 12:18:04 +0200 From: Avi Kivity MIME-Version: 1.0 Subject: Re: [Qemu-devel] [RFC] More robust migration References: <499EBFD8.50307@amd.com> <200902201647.27138.paul@codesourcery.com> <20090223035140.GA23719@shareable.org> <200902231155.09093.paul@codesourcery.com> <20090223220708.GA8471@shareable.org> In-Reply-To: <20090223220708.GA8471@shareable.org> 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: qemu-devel@nongnu.org Cc: Paul Brook Jamie Lokier wrote: > Paul Brook wrote: > >> I never said you need the same host. All the save/restore code >> should be host independent. It should be possible to save state on >> (say) i386 and restore on ppc64. Anything that prevents this is IMO >> a bug. >> >> For KVM you're likely to need a cpu with at least as many features >> as the old one, but that's the price you pay for using host hardware >> features. >> > > I'd prefer the "host hardware features" to be an acceleration > mechanism, than something which makes a VM dependent on the specific > host it's running on. > > Can't KVM invoke QEMU's emulation capabilities for those things it > cannot provide itself because of missing host abilities? Some host hardware features are invisible to the guest (so they are just acceleration mechanisms). Others are visible to the guest (like instruction set extensions) but they can be turned off using cpuid so that mixed-feature migration pools are possible. -- error compiling committee.c: too many arguments to function