Re: [Qemu-devel] [PATCH 3/8] fdc: Introduce fdctrl->phase

["Dr. David Alan Gilbert" <dgilbert@redhat.com>]

* Kevin Wolf (kwolf@redhat.com) wrote:
> Am 20.05.2015 um 14:07 hat Peter Maydell geschrieben:
> > On 20 May 2015 at 12:55, John Snow <jsnow@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 / dgilbert@redhat.com / Manchester, UK