[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Kevin Wolf
Subject: Re: [Qemu-devel] [PATCH 3/8] fdc: Introduce fdctrl->phase
Date: Thu, 21 May 2015 11:42:33 +0200
User-agent: Mutt/1.5.21 (2010-09-15)

Am 20.05.2015 um 14:07 hat Peter Maydell geschrieben:
> On 20 May 2015 at 12:55, John Snow <address@hidden> 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.

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


reply via email to

[Prev in Thread] Current Thread [Next in Thread]