From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43)
	id 1LbixI-0001Kd-ST
	for qemu-devel@nongnu.org; Mon, 23 Feb 2009 17:07:16 -0500
Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43)
	id 1LbixF-0001Jf-Tc
	for qemu-devel@nongnu.org; Mon, 23 Feb 2009 17:07:14 -0500
Received: from [199.232.76.173] (port=41296 helo=monty-python.gnu.org)
	by lists.gnu.org with esmtp (Exim 4.43) id 1LbixE-0001JO-Lp
	for qemu-devel@nongnu.org; Mon, 23 Feb 2009 17:07:13 -0500
Received: from mail2.shareable.org ([80.68.89.115]:59927)
	by monty-python.gnu.org with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA1:32)
	(Exim 4.60) (envelope-from <jamie@shareable.org>) id 1LbixE-0006sn-1f
	for qemu-devel@nongnu.org; Mon, 23 Feb 2009 17:07:12 -0500
Date: Mon, 23 Feb 2009 22:07:08 +0000
From: Jamie Lokier <jamie@shareable.org>
Subject: Re: [Qemu-devel] [RFC] More robust migration
Message-ID: <20090223220708.GA8471@shareable.org>
References: <499EBFD8.50307@amd.com> <200902201647.27138.paul@codesourcery.com>
	<20090223035140.GA23719@shareable.org>
	<200902231155.09093.paul@codesourcery.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <200902231155.09093.paul@codesourcery.com>
Reply-To: qemu-devel@nongnu.org
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: Paul Brook <paul@codesourcery.com>
Cc: qemu-devel@nongnu.org

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?

-- Jamie