[Qemu-devel] Re: Live migration protocol, device features, ABIs and other beasts

[Juan Quintela <quintela@redhat.com>]

"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.