* Kevin Wolf (kw...@redhat.com) wrote: > Am 20.05.2015 um 14:07 hat Peter Maydell geschrieben: > > On 20 May 2015 at 12:55, John Snow <js...@redhat.com> wrote: > > > So even if /currently/ we can reconstitute it from the register values, > > > we may eventually be unable to. > > > > > > post_load will work for now, but I fear the case (in ten years) when > > > someone else cleans up FDC code but fails to realize that the phase is > > > not explicitly migrated. > > > > I assumed we would only do the post-load thing if the > > source for migration doesn't migrate phase (however we > > phrase that in a vmstate struct). > > I think if we extend the VMState, then we have two options. I'm not > exactly sure how they work in details, but I'll try an educated guess - > Juan, please correct me if I'm wrong: > > 1. We increase version_id and add the new field at the end. This breaks > backwards migration; on forward migration the new field would be > initialised with 0 and a post_load handler could check the old > version_id to calculate the phase from register bits. > > 2. We add a subsection for the phase, and declare one phase to be the > default (most likely the command phase) for which a subsection is not > sent. In this case, the destination can't distinguish between a > missing subsection because the source was running an old qemu or > because it is the default phase. Unclear whether post_load should > recalculate the phase or not.
There's another variant; add a subsection and always send it for new machine types. > If the above is correct, I'm afraid that the third option - which > doesn't address John's (valid) concerns - would be the most reasonable: > > 3. Don't add any VMState fields now and just do the post_load handler. > If we ever extend fdc in a way that makes it impossible to > reconstruct the phase from other migrated state, we add a subsection > that is only sent in cases where it differs from the reconstructed > value. Dave > > Kevin > -- Dr. David Alan Gilbert / dgilb...@redhat.com / Manchester, UK