From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:47671) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YvN01-0006WR-IP for qemu-devel@nongnu.org; Thu, 21 May 2015 05:42:49 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YvN00-0004o4-7G for qemu-devel@nongnu.org; Thu, 21 May 2015 05:42:45 -0400 Date: Thu, 21 May 2015 11:42:33 +0200 From: Kevin Wolf Message-ID: <20150521094233.GA6143@noname.redhat.com> References: <1432049762-2184-4-git-send-email-kwolf@redhat.com> <555BA2A6.5090602@redhat.com> <20150520075410.GA4917@noname.redhat.com> <20150520084336.GE4917@noname.redhat.com> <555C7645.8000400@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Subject: Re: [Qemu-devel] [PATCH 3/8] fdc: Introduce fdctrl->phase List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Peter Maydell Cc: John Snow , QEMU Developers , qemu-block@nongnu.org, quintela@redhat.com 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. 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. Kevin