From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43)
	id 1NCw3k-00051T-Uz
	for qemu-devel@nongnu.org; Tue, 24 Nov 2009 09:08:01 -0500
Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43)
	id 1NCw3g-0004zv-DL
	for qemu-devel@nongnu.org; Tue, 24 Nov 2009 09:08:00 -0500
Received: from [199.232.76.173] (port=47371 helo=monty-python.gnu.org)
	by lists.gnu.org with esmtp (Exim 4.43) id 1NCw3g-0004zq-65
	for qemu-devel@nongnu.org; Tue, 24 Nov 2009 09:07:56 -0500
Received: from mx1.redhat.com ([209.132.183.28]:57744)
	by monty-python.gnu.org with esmtp (Exim 4.60)
	(envelope-from <mst@redhat.com>) id 1NCw3f-0002E5-Me
	for qemu-devel@nongnu.org; Tue, 24 Nov 2009 09:07:55 -0500
Date: Tue, 24 Nov 2009 16:05:17 +0200
From: "Michael S. Tsirkin" <mst@redhat.com>
Message-ID: <20091124140517.GL2405@redhat.com>
References: <4B0952C9.9010803@redhat.com> <m3my2d4euy.fsf@neno.neno>
	<4B0A899F.2090805@codemonkey.ws> <m3my2dwcpk.fsf@neno.neno>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <m3my2dwcpk.fsf@neno.neno>
Subject: [Qemu-devel] Re: Live migration protocol, device features,
	ABIs and other beasts
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: Juan Quintela <quintela@redhat.com>
Cc: dlaor@redhat.com, qemu-devel <qemu-devel@nongnu.org>

On Mon, Nov 23, 2009 at 03:13:59PM +0100, Juan Quintela wrote:
> Anthony Liguori <anthony@codemonkey.ws> wrote:
> > Juan Quintela wrote:
> >> Dor Laor <dlaor@redhat.com> wrote:
> >>>     
> >>
> >> My idea here is that we need to have further use of machine
> >> descriptions, once that is done, we need something like a new property
> >> for qdev (version?).  Once there, each device could do:
> >> - if version != last_version -> die (what it happens now)
> >> - do someting sensible, not use the "new" features not existing on that
> >>   version
> >> - edit the savevm format in an easy way.
> >>   
> >
> > 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.

-- 
MST