From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1NDI98-0000Rs-Gk for qemu-devel@nongnu.org; Wed, 25 Nov 2009 08:43:02 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1NDI96-0000Py-FK for qemu-devel@nongnu.org; Wed, 25 Nov 2009 08:43:01 -0500 Received: from [199.232.76.173] (port=56399 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NDI96-0000Pq-7x for qemu-devel@nongnu.org; Wed, 25 Nov 2009 08:43:00 -0500 Received: from mx1.redhat.com ([209.132.183.28]:47660) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1NDI95-0005pg-Ty for qemu-devel@nongnu.org; Wed, 25 Nov 2009 08:43:00 -0500 Received: from int-mx04.intmail.prod.int.phx2.redhat.com (int-mx04.intmail.prod.int.phx2.redhat.com [10.5.11.17]) by mx1.redhat.com (8.13.8/8.13.8) with ESMTP id nAPDgwNb013365 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Wed, 25 Nov 2009 08:42:59 -0500 Date: Wed, 25 Nov 2009 15:40:21 +0200 From: "Michael S. Tsirkin" Subject: Re: [Qemu-devel] Re: Live migration protocol, device features, ABIs and other beasts Message-ID: <20091125134021.GC9333@redhat.com> References: <4B0952C9.9010803@redhat.com> <4B0A899F.2090805@codemonkey.ws> <20091124140517.GL2405@redhat.com> <4B0D32F1.3010008@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4B0D32F1.3010008@redhat.com> List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Gerd Hoffmann Cc: dlaor@redhat.com, qemu-devel , Juan Quintela On Wed, Nov 25, 2009 at 02:36:49PM +0100, Gerd Hoffmann wrote: > On 11/24/09 15:05, Michael S. Tsirkin wrote: >> On Mon, Nov 23, 2009 at 03:13:59PM +0100, Juan Quintela wrote: >>>> But this would only kick in when using pc-0.11 or something, right? >>> >>> Yeap. >>> >>> At this point, pc-0.10 is just: >>> >>> static QEMUMachine pc_machine_v0_10 = { >>> .name = "pc-0.10", >>> .desc = "Standard PC, qemu 0.10", >>> .init = pc_init_pci, >>> .max_cpus = 255, >>> .compat_props = (CompatProperty[]) { >>> { >>> .driver = "virtio-blk-pci", >>> .property = "class", >>> .value = stringify(PCI_CLASS_STORAGE_OTHER), >>> },{ >>> .driver = "virtio-console-pci", >>> .property = "class", >>> .value = stringify(PCI_CLASS_DISPLAY_OTHER), >>> },{ >>> .driver = "virtio-net-pci", >>> .property = "vectors", >>> .value = stringify(0), >>> },{ >>> .driver = "virtio-blk-pci", >>> .property = "vectors", >>> .value = stringify(0), >>> }, >>> { /* end of list */ } >>> }, >>> >>> But to really make it work, we need to take a list of each savevm format >>> change and put it here. Notice that several changes are needed: >>> - savevm infrastructure save functions don't know about version id >>> - devices don't know to "behave" as other version >>> - other things that I have probably missed >>> >>> Later, Juan. >> >> Why do you think this the right place for it, I wonder? >> This describes the machine, it does not seem to have >> anything to do with how we migrate it. > > Well. It turns off MSI for virtio-net-pci when you start it with -M > pc-0.10. Which makes virtio-net-pci savevm sections compatible with the > qemu 0.10 ... > > We could add a DeviceState->savevm field and make that available as > property for devices which need to support multiple versions. Then you > we can use the compat properties to switch back to the older format with > -M pc-0.10. > > cheers, > Gerd I'm confused sorry. Of course when you want to migrate to qemu 0.10 you must have a compatible machine. And savevm format has nothing to do with it IMO, so MSI is orthogonal to this discussion. It just shows that it was smart not to save MSI state when MSI is not present (/me pats self on the back). In this thread we were discussing changes like pvclock bug, where we change savevm format without changing the machine, or almost without changing the machine. -- MST