From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:48840) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YvN54-0001uQ-Rb for qemu-devel@nongnu.org; Thu, 21 May 2015 05:48:02 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YvN4z-0006gb-Ld for qemu-devel@nongnu.org; Thu, 21 May 2015 05:47:58 -0400 Date: Thu, 21 May 2015 10:47:46 +0100 From: "Dr. David Alan Gilbert" Message-ID: <20150521094746.GE2129@work-vm> References: <555BA2A6.5090602@redhat.com> <20150520075410.GA4917@noname.redhat.com> <20150520084336.GE4917@noname.redhat.com> <555C7645.8000400@redhat.com> <20150521094233.GA6143@noname.redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20150521094233.GA6143@noname.redhat.com> Subject: Re: [Qemu-devel] [PATCH 3/8] fdc: Introduce fdctrl->phase List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Kevin Wolf Cc: Peter Maydell , John Snow , QEMU Developers , qemu-block@nongnu.org, quintela@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 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