Re: [Qemu-devel] KVM call agenda for October 11th

[Anthony Liguori <anthony@codemonkey.ws>]

On 10/11/2011 08:21 AM, Avi Kivity wrote:
> On 10/11/2011 03:01 PM, Anthony Liguori wrote:
>> On 10/11/2011 06:48 AM, Avi Kivity wrote:
>>> On 10/10/2011 01:35 PM, Juan Quintela wrote:
>>>> Hi
>>>>
>>>> Please send in any agenda items you are interested in covering.
>>>>
>>>
>>> Subsections, version numbers, migration to older releases.
>>
>> Problem with subsections:
>>
>> The encoding of a subsection within an embedded structure is ambiguous
>> because the subsection occurs at the end of the structure.  QEMU may
>> mistakenly parse what follows the structure as the end of subsection
>> deliminator.
>>
>> Possible solutions:
>>
>> 1) Juan has a series that adds heuristics to better match the EOS
>> deliminator. While not 100% perfect, it should handle practically all
>> possible cases.
>>
>> The main issue is that it's not present in older QEMUs which means
>> migrating a subsection within a structure to an old QEMU that doesn't
>> have this heuristic could fail.
>>
>> Ways to mitigate: force all devices with subsections to bump their
>> version number.  Wave our hands around and claim that the new version
>> requires the subsection heuristics to be present.
>>
>> 2) Add Paolo's protocol change.  This will cause a migration flag
>> day.  Since we want to switch to ASN.1 too, we'll have another flag
>> day for the next release too.
>>
>> 3) Change subsection protocol more dramatically than Paolo's change
>> (make subsections stand alone sections).  Not clear how much effort
>> this is.
>>
>> 4) Avoid subsections until we introduce a new wire protocol based on
>> ASN.1 that can better handle concepts like subsections.  This misses
>> some opportunity for backwards compatibility in the short term but
>> avoids repeated flag days.
>>
>
> 5) Implement subsections through the wire as top-level sections (as
> originally intended).  Keep existing subsections with (1).

That was (3).

> btw, it's reasonable to require that backwards migration is only to a
> fully updated stable release, so we can do 5) too, or backport 1).

But given the choice of a nasty silent failure to an not-quite-up-to-date stable 
release or failing migration to a fully up-to-date stable release, I think it's 
better that we err on the side of caution.

Not being able to migrate because of a recoverable failure is annoying.  Having 
a silent failure that possible results in corruption is unacceptable.

Regards,

Anthony Liguori