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
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
