From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1KneMd-0000RS-P1 for qemu-devel@nongnu.org; Wed, 08 Oct 2008 15:06:27 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1KneMc-0000Pf-6k for qemu-devel@nongnu.org; Wed, 08 Oct 2008 15:06:27 -0400 Received: from [199.232.76.173] (port=54833 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1KneMb-0000PW-F5 for qemu-devel@nongnu.org; Wed, 08 Oct 2008 15:06:25 -0400 Received: from mail-gx0-f19.google.com ([209.85.217.19]:48365) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1KneMa-00010w-H4 for qemu-devel@nongnu.org; Wed, 08 Oct 2008 15:06:25 -0400 Received: by gxk12 with SMTP id 12so9170417gxk.10 for ; Wed, 08 Oct 2008 12:06:23 -0700 (PDT) Message-ID: Date: Wed, 8 Oct 2008 22:06:22 +0300 From: "Blue Swirl" Subject: Re: [Qemu-devel] Snapshots not bound to an architecture? In-Reply-To: <48EBC8F5.4070808@codemonkey.ws> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <48EBC514.7010209@codemonkey.ws> <200810072130.07903.paul@codesourcery.com> <48EBC8F5.4070808@codemonkey.ws> 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 On 10/7/08, Anthony Liguori wrote: > Paul Brook wrote: > > > On Tuesday 07 October 2008, Anthony Liguori wrote: > > > > > > > Blue Swirl wrote: > > > > > > > > > > Hi, > > > > > > > > While testing the savevm/loadvm functions, I noticed that it's > > > > possible to attempt to load a snapshot made for entirely different > > > > architecture. There are a lot of warnings, of course. > > > > > > > > Could we prevent this somehow? Or is there a use case for this, for > > > > example loading a snapshot made on i386 to an x86_64 emulator? > > > > > > > > > > > I think we should introduce a machine section for save/restore that > > > included that information. It should also be versioned in such a way > > > that it could be incremented whenever a new piece of hardware is added > > > to the default machine type. > > > > > > > > > > Using a single version number to determine the "base" machine is IMHO a > bad idea. > > > > I should have said, that I expected this to be an intermediate step. > > > > The base peripherals should be identified (and mismatches detected) that > same way as any other peripherals. > > > > > > Yes. This is particularly important in the context of hot plug because the > bus/dev/fn of the plugged device may be different than if the device were > just added directly. > > > > The simplest way to avoid loading the wrong type of machine is to give the > cpus different names (e.g. cpu_i386/cpu_amd64) instead of just calling them > "cpu". > > > > > > Yes, that works too, but it breaks backwards compatibility in a way that's > hard to reconcile. Bumping the version of "cpu" and including a machine > type identifier would also work and would be easier to do in a backwards > compatible way. There could be a compatibility check in the loadvm code just for "cpu" and "cpu_common". The check would be removed when no target wants to handle those versions anymore.