From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43)
	id 1NDI3K-0002mE-D2
	for qemu-devel@nongnu.org; Wed, 25 Nov 2009 08:37:02 -0500
Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43)
	id 1NDI3F-0002i8-IO
	for qemu-devel@nongnu.org; Wed, 25 Nov 2009 08:37:01 -0500
Received: from [199.232.76.173] (port=45798 helo=monty-python.gnu.org)
	by lists.gnu.org with esmtp (Exim 4.43) id 1NDI3F-0002hq-7i
	for qemu-devel@nongnu.org; Wed, 25 Nov 2009 08:36:57 -0500
Received: from mx1.redhat.com ([209.132.183.28]:56743)
	by monty-python.gnu.org with esmtp (Exim 4.60)
	(envelope-from <quintela@redhat.com>) id 1NDI3F-0005AG-1B
	for qemu-devel@nongnu.org; Wed, 25 Nov 2009 08:36:57 -0500
From: Juan Quintela <quintela@redhat.com>
In-Reply-To: <20091125093237.GA7285@redhat.com> (Michael S. Tsirkin's message
	of "Wed, 25 Nov 2009 11:32:37 +0200")
References: <4B0952C9.9010803@redhat.com> <m3my2d4euy.fsf@neno.neno>
	<4B0BB7F6.5090103@redhat.com> <20091124140144.GK2405@redhat.com>
	<m3r5rot34h.fsf@neno.neno> <20091124160500.GD6737@redhat.com>
	<m33a43rlx4.fsf@neno.neno> <20091125093237.GA7285@redhat.com>
Date: Wed, 25 Nov 2009 14:36:22 +0100
Message-ID: <m3d436ybe1.fsf@neno.neno>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
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: "Michael S. Tsirkin" <mst@redhat.com>
Cc: Dor Laor <dlaor@redhat.com>, qemu-devel <qemu-devel@nongnu.org>

"Michael S. Tsirkin" <mst@redhat.com> wrote:
> On Wed, Nov 25, 2009 at 10:30:47AM +0100, Juan Quintela wrote:
>> "Michael S. Tsirkin" <mst@redhat.com> wrote:
>> > On Tue, Nov 24, 2009 at 03:21:34PM +0100, Juan Quintela wrote:
>> 
>> > A device already supports load for a range
>> > of versions between X and Y. We want to support
>> > saving to a range of versions.
>> >
>> > Which versions to use is a separate decision
>> > which should be taken on run time, not
>> > at startup time.
>> 
>> Not in the general case.
>
> If that means "not in all cases", I agree.
> But it seems pretty common for bugfixes.
>
>> Think that v8 brings featureX to one device.  If you _know_ that you don't
>> want to use feature X, startup time is the proper place.  Important
>> thing is not the savevm format (we can do any change here), what we
>> really need is that the guest still runs on the destination, and for
>> that you can't change the hardware too much.
>> 
>> Later, Juan.
>
> I think it's clear: if you change guest visible properties
> these are features that might belong in machine description.
> If not - they don't belong in machine description.

Ah, ok.  Now we have some agreement (this second part).
About the 1st part, the difference is that I don't want yet another
mechanism for this bugfixes, just use the same one that the machine
description.

I think we can state it as:
- have different ways from bug fixes that guest visible changes
  pro: bugfixes get easier,
  con: we have _two_ mechanism

- have a single way for bugfixes and guest visible changes
  pro: we only have one mechanism
  con: bugfixes are "elevated to the machine description"

We can stop discussing here, because clearly none is better than the
other.  We have to just make a choice of one with its advantages and
disadvantages.

Later, Juan.