From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1KnJL0-0000oE-AK for qemu-devel@nongnu.org; Tue, 07 Oct 2008 16:39:22 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1KnJKz-0000ns-MO for qemu-devel@nongnu.org; Tue, 07 Oct 2008 16:39:21 -0400 Received: from [199.232.76.173] (port=40137 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1KnJKz-0000no-Ht for qemu-devel@nongnu.org; Tue, 07 Oct 2008 16:39:21 -0400 Received: from qw-out-1920.google.com ([74.125.92.144]:56701) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1KnJKz-000815-6R for qemu-devel@nongnu.org; Tue, 07 Oct 2008 16:39:21 -0400 Received: by qw-out-1920.google.com with SMTP id 5so783868qwc.4 for ; Tue, 07 Oct 2008 13:39:20 -0700 (PDT) Message-ID: <48EBC8F5.4070808@codemonkey.ws> Date: Tue, 07 Oct 2008 15:39:17 -0500 From: Anthony Liguori MIME-Version: 1.0 Subject: Re: [Qemu-devel] Snapshots not bound to an architecture? References: <48EBC514.7010209@codemonkey.ws> <200810072130.07903.paul@codesourcery.com> In-Reply-To: <200810072130.07903.paul@codesourcery.com> Content-Type: text/plain; charset=UTF-8; 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: Paul Brook Cc: qemu-devel@nongnu.org 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. Regards, Anthony Liguori > Paul >