[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Juan Quintela
Subject: [Qemu-devel] Re: Live migration protocol, device features, ABIs and other beasts
Date: Wed, 25 Nov 2009 14:36:22 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1 (gnu/linux)

"Michael S. Tsirkin" <address@hidden> wrote:
> On Wed, Nov 25, 2009 at 10:30:47AM +0100, Juan Quintela wrote:
>> "Michael S. Tsirkin" <address@hidden> 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

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

Later, Juan.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]