Re: [Qemu-devel] [PULL 8/9] static checker: e1000-82540em got aliased to e1000

[Jason Wang]

On 04/06/2016 09:52 PM, Amit Shah wrote:
> On (Wed) 06 Apr 2016 [09:48:19], Jason Wang wrote:
>>
>> On 04/05/2016 09:32 PM, Dr. David Alan Gilbert wrote:
>>> * Amit Shah (address@hidden) wrote:
>>>> On (Tue) 23 Feb 2016 [15:02:58], Jason Wang wrote:
>>>>>>> This means that 2.5 cannot migrate 2.4 virtual machines, right?  Is that
>>>>>>> something we want to rectify in 2.6 by making e1000-82540em an alias of
>>>>>>> e1000 (instead of the other way round)?
>>>>>> You're right; I misread it.  With that commit (8304402033):
>>>>>>
>>>>>> 2.4 with e1000-82540em will not migrate to 2.5 with e1000-82540em.
>>>>>>
>>>>>> This is despite they're aliased (so the cmdline is backward
>>>>>> compatible), but the migration device name actually changed.
>>>>>>
>>>>>> Of course, 2.5->2.4 will also not work.
>>>>>>
>>>>>> Since 2.4 emits 'e1000-82540em' as the device name in the migration
>>>>>> stream, and 2.5 emits just 'e1000', we have two different names for
>>>>>> the same device in two versions.
>>>>>>
>>>>>> To fix this, we'll need a hack on the dest side to allow e1000 and
>>>>>> e1000-82540em in the migration stream for the device, and this can be
>>>>>> done for 2.6 and 2.5.stable.
>>>>>>
>>>>>> Jason, can you attempt this?
>>>>>>
>>>>> Sure, but just need to understand the "problem". If I understand this
>>>>> correctly, the issue only happen for JSON description at the end of
>>>>> migration stream, and it won't break migration in fact?
>>>> No, this does break migration.
>>>>
>>>> The stream contained 'e1000-82540em' as the section header for the
>>>> device earlier.  It now only has 'e1000'.  So a newer qemu will only
>>>> accept 'e1000', but not 'e1000-82540em' (from an older release).
>>> OK, so do we need to get this fixed for 2.6 - i.e. now.
>>>
>>> Dave
>> Sorry for the late response.
>>
>> Have a try with 2.4 -> 2.5 migration and it works. Looking at
>> save_section_header(), it will save se->idstr which seems always be
>> "e1000" even if e1000-82540em is used in cli, or is there anything I missed?
> OK, sorry for the wrong alarm.
>
> The VMStateDescription's 'name' field has remained the same; but the
> section name has changed, which is fine (that isn't transmitted over
> the wire).  So my initial reading was correct - and the whitelist I
> added in 1483e0d74dcfd183ff46dd63cc57e1fe8b775bf8 is fine.
>
> So nothing needed for the migration stream.
>
> Thanks, Jason.
>
>               Amit
>

Thanks for the confirmation.