qemu-devel
[Top][All Lists]
Advanced

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




reply via email to

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