From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:39586) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QTZ1U-00079p-K6 for qemu-devel@nongnu.org; Mon, 06 Jun 2011 08:35:13 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1QTZ1S-00043P-SS for qemu-devel@nongnu.org; Mon, 06 Jun 2011 08:35:12 -0400 Received: from mail-pz0-f45.google.com ([209.85.210.45]:65303) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QTZ1S-00041x-Jq for qemu-devel@nongnu.org; Mon, 06 Jun 2011 08:35:10 -0400 Received: by pzk30 with SMTP id 30so1985498pzk.4 for ; Mon, 06 Jun 2011 05:35:09 -0700 (PDT) Sender: Paolo Bonzini Message-ID: <4DECC977.7070501@redhat.com> Date: Mon, 06 Jun 2011 14:35:03 +0200 From: Paolo Bonzini MIME-Version: 1.0 References: <1306836595-8481-1-git-send-email-kwolf@redhat.com> In-Reply-To: <1306836595-8481-1-git-send-email-kwolf@redhat.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [RFC][PATCH] ide: Break migration by splitting error status from status register List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Kevin Wolf Cc: quintela@redhat.com, qemu-devel@nongnu.org, armbru@redhat.com On 05/31/2011 12:09 PM, Kevin Wolf wrote: > When adding the werror=stop mode, some flags were added to s->status > which are used to determine what kind of operation should be restarted > when the VM is continued. > > Unfortunately, it turns out that s->status is in fact a device register > and as such is visible to the guest (some of the abused bits are even > writable for the guest). > > Splitting the internal status and the status register into two different > variables is easy enough, but this will break migration: We must have a > way to detect what s->status really means. Is it only the status register > (as used by new versions) or do we have to extract internal error status > flags? > > Here we seem to be lacking some kind of optional subsection that would > be simply ignored by older versions, but can contain information for new > versions. Is there any precedence on how to solve this? You need to stop writing either status field to the migration stream; instead you recreate the "wrong" status field before saving, and set the "right" status fields from the saved data after loading. On top of this, you use a subsection to save bits 3-7 of the "real" IDE status registers. These had been hijacked, so there is no room for them in the migration stream. Of course, the subsection is needed only if any of those bits is set. Paolo