From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Lbltk-0003La-N3 for qemu-devel@nongnu.org; Mon, 23 Feb 2009 20:15:48 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1Lbltj-0003LO-6O for qemu-devel@nongnu.org; Mon, 23 Feb 2009 20:15:48 -0500 Received: from [199.232.76.173] (port=56287 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Lbltj-0003LL-4p for qemu-devel@nongnu.org; Mon, 23 Feb 2009 20:15:47 -0500 Received: from qw-out-1920.google.com ([74.125.92.150]:3253) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1Lblti-0005UF-RX for qemu-devel@nongnu.org; Mon, 23 Feb 2009 20:15:46 -0500 Received: by qw-out-1920.google.com with SMTP id 4so760806qwk.4 for ; Mon, 23 Feb 2009 17:15:46 -0800 (PST) Message-ID: <49A34A22.8000106@codemonkey.ws> Date: Mon, 23 Feb 2009 19:15:14 -0600 From: Anthony Liguori 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? > In theory, software can do anything :-) In practice, it's pretty nasty to mix TCG execution with direct execution. TCG doesn't guarantee atomicity of translated instructions so if you had TCG running one VCPU and bare metal running the other badness could occur. Plus, TCG has hidden state that needs to be synchronized between the two. Yeah, you could halt all VCPUs and just run one in TCG, or some other equally hackish thing. But the point is, it's not easy and since it's not a tremendously popular thing to do, noone's working on it. We have much more important low-hanging fruit (like making qcow2 not suck). Regards, Anthony Liguori > -- Jamie > > >