[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [PATCH 1/1] s390x/migration: Introduce 2.4 machine
From: |
Christian Borntraeger |
Subject: |
Re: [Qemu-devel] [PATCH 1/1] s390x/migration: Introduce 2.4 machine |
Date: |
Wed, 01 Jul 2015 12:20:59 +0200 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 |
Am 01.07.2015 um 11:56 schrieb Juan Quintela:
> Christian Borntraeger <address@hidden> wrote:
>
> First of all
>
> Reviewed-by: Juan Quintela <address@hidden>
>
> For the patch.
>
> But one said that, I don't agree with the commint text.
So let's just drop this sentence
>> While one can argue that section footer should be enabled
>> explicitely for new versions instead of disabled for old ones,
And rephrase to
"
This pinpoints to a problem of s390-ccw-machines: it needs to
be versioned to allow common code changes to add compat handling.
"
Conny, want me to resend or can you fixup the patch description when
taking this patch?
>
>
>> The section footer changes commit f68945d42bab ("Add a protective
>> section footer") and commit 37fb569c0198 ("Disable section footers
>> on older machine types") broke migration for any non-versioned
>> machines.
>
> If broke migration for 2.4 -> 2.3 for machines that don't care about
> compatibility. If they care, they are versioned O:-) Right now ppc &
> x86. I guess that s390 and arm will follow in due curse.
yes. That is what my 2nd sentence says: we are not versioned and that is
the main issue to solve.
>> this pinpoints to a problem of s390-ccw-machines: it needs to
>> be versioned to be compatible with future changes in common
>> code data structures such as section footers.
>
> It is done explicitely the other way around. New way is the default
> way. If we did it in a special way in the past, we add a switch. If at
> some point we remove the old machine type for any reason, we don't have
> to change anything on $latest.
>
> Basically the idea here is that (until now) only x86 cared about
> backwards compatibility, so when a migration changed happened because it
> was good for any reason, normal devices do changes, and then x86 try to
> fix the pieces after the fact. That is going to continue, just that now
> more architectures care, and then we should detect this kind of problems
> much earlier.
>
>> Let's introduce a version scheme for s390-ccw-virtio machines.
>> We will use the old s390-ccw-virtio name as alias to the latest
>> version as all existing libvirt XML for the ccw type were expanded
>> by libvirt to that name.
>>
>> The only downside of this patch is, that the old alias s390-ccw
>> will no longer be available as machines can have only one alias,
>> but it should not really matter.
>
> Should we change to a list?
list of aliases? Why not, we would use it.