On Mon, Feb 07, 2011 at 08:23:08PM -0600, Anthony Liguori wrote:
On 02/07/2011 03:52 PM, Michael S. Tsirkin wrote:
How does it? We need to know we are saving in 0.13
format and skip the new subsection, otherwise
0.13 will see a subsection it does not recognize
and exit.
If you used subsections for flow control, presumably you would only
send the new savevm data if you had data buffered.
If you add a qdev property to enable/disable flow control, then if
it's disabled, you naturally would never send the subsection because
you'd never buffer data. So no explicit code is needed to support
migration.
But the result is we get a new property that we can never remove
as any qdev property is part of interface.
The difficult case is when you truly need to change the savevm
version. I don't think we have a proper fix for this because
versions are linear so the proposed patch certainly wouldn't be a
good way to do it. if flow_control=0 causes savevm 3 to be used
instead of 4, and then the next_feature=0 causes savevm 4 to be used
instead of 5, the semantics of flow_control=0,next_feature=1 becomes
problematic.
But as long as the feature has isolated state, we can solve the
problem robustly with subsections.
Regards,
Anthony Liguori
I see. I'm unhappy with the facts that
1. if (feature) is spread all over the code instead
of just in migration