From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:45210) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Yv2bO-0006eP-A7 for qemu-devel@nongnu.org; Wed, 20 May 2015 07:55:59 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Yv2bN-000719-9s for qemu-devel@nongnu.org; Wed, 20 May 2015 07:55:58 -0400 Message-ID: <555C7645.8000400@redhat.com> Date: Wed, 20 May 2015 07:55:49 -0400 From: John Snow MIME-Version: 1.0 References: <1432049762-2184-1-git-send-email-kwolf@redhat.com> <1432049762-2184-4-git-send-email-kwolf@redhat.com> <555BA2A6.5090602@redhat.com> <20150520075410.GA4917@noname.redhat.com> <20150520084336.GE4917@noname.redhat.com> In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit 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 , Kevin Wolf Cc: QEMU Developers , qemu-block@nongnu.org On 05/20/2015 05:24 AM, Peter Maydell wrote: > On 20 May 2015 at 09:43, Kevin Wolf wrote: >> Am 20.05.2015 um 10:06 hat Peter Maydell geschrieben: >>> That handles migration, which is good. But I still think that >>> storing the same information in two places in the device >>> state (phase field and the register fields) is error-prone. >> >> That's actually my point. The registers are accessed everywhere in the >> code, whereas phase transitions are in very few well-defined places >> (there are exactly four of them, iirc). If they get out of sync, chances >> are that the bug is in the register value, not in the phase. When we >> know what phase we're in, we can assert the bits and actually catch such >> bugs. >> >>> If we want to switch to having a phase field we should calculate >>> the relevant register bits on demand based on the phase, rather >>> than keeping both copies of the state in sync manually. >> >> That doesn't work, unfortunately. Some register bits imply a specific >> phase (assuming correct code), but you can't derive the exact bits just >> from the phase. > > Having now dug out a copy of the 82078 spec, I agree that the state > isn't derivable purely from the register values in the general case. > The controller clearly has a state machine internally but it doesn't > surface that in the register state except indirectly. > > -- PMM > 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.