[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
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.
- Re: [Qemu-devel] Re: Live migration protocol, device features, ABIs and other beasts, (continued)
- Re: [Qemu-devel] Re: Live migration protocol, device features, ABIs and other beasts, Michael S. Tsirkin, 2009/11/25
- [Qemu-devel] Re: Live migration protocol, device features, ABIs and other beasts, Juan Quintela, 2009/11/25
- [Qemu-devel] Re: Live migration protocol, device features, ABIs and other beasts, Michael S. Tsirkin, 2009/11/25
[Qemu-devel] Re: Live migration protocol, device features, ABIs and other beasts, Dor Laor, 2009/11/24
- [Qemu-devel] Re: Live migration protocol, device features, ABIs and other beasts, Michael S. Tsirkin, 2009/11/24
- [Qemu-devel] Re: Live migration protocol, device features, ABIs and other beasts, Juan Quintela, 2009/11/24
- [Qemu-devel] Re: Live migration protocol, device features, ABIs and other beasts, Michael S. Tsirkin, 2009/11/24
- [Qemu-devel] Re: Live migration protocol, device features, ABIs and other beasts, Michael S. Tsirkin, 2009/11/24
- [Qemu-devel] Re: Live migration protocol, device features, ABIs and other beasts, Juan Quintela, 2009/11/25
- [Qemu-devel] Re: Live migration protocol, device features, ABIs and other beasts, Michael S. Tsirkin, 2009/11/25
- [Qemu-devel] Re: Live migration protocol, device features, ABIs and other beasts,
Juan Quintela <=
[Qemu-devel] Re: Live migration protocol, device features, ABIs and other beasts, Michael S. Tsirkin, 2009/11/24