From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from eggs.gnu.org ([208.118.235.92]:36480)
	by lists.gnu.org with esmtp (Exim 4.71)
	(envelope-from <flukshun@gmail.com>) id 1UeulA-0003ar-DX
	for qemu-devel@nongnu.org; Tue, 21 May 2013 18:10:22 -0400
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
	(envelope-from <flukshun@gmail.com>) id 1Ueul9-00039o-F1
	for qemu-devel@nongnu.org; Tue, 21 May 2013 18:10:20 -0400
Received: from mail-ie0-x22f.google.com ([2607:f8b0:4001:c03::22f]:58818)
	by eggs.gnu.org with esmtp (Exim 4.71)
	(envelope-from <flukshun@gmail.com>) id 1Ueul9-00039j-9Q
	for qemu-devel@nongnu.org; Tue, 21 May 2013 18:10:19 -0400
Received: by mail-ie0-f175.google.com with SMTP id s9so3329606iec.20
	for <qemu-devel@nongnu.org>; Tue, 21 May 2013 15:10:18 -0700 (PDT)
Sender: fluxion <flukshun@gmail.com>
Date: Tue, 21 May 2013 17:07:33 -0500
From: mdroth <mdroth@linux.vnet.ibm.com>
Message-ID: <20130521220733.GH2441@vm>
References: <1369136018.15129.1538.camel@eboracum.office.bytemark.co.uk>
	<20130521165556.GA13602@vm> <20130521172608.GB13602@vm>
	<CAFEAcA9fG3vANr2T2EwspUH5dypBKgo7ox=YiAYOwjpJchMptg@mail.gmail.com>
	<20130521204338.GG2441@vm>
	<CAFEAcA8_y_MbswkamHOge8b3nhM_S_6wo5CpOfi3pwZPGdEJzw@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <CAFEAcA8_y_MbswkamHOge8b3nhM_S_6wo5CpOfi3pwZPGdEJzw@mail.gmail.com>
Subject: Re: [Qemu-devel] (Another) 1.4.1 -> 1.5.0 migration failure
List-Id: <qemu-devel.nongnu.org>
List-Unsubscribe: <https://lists.nongnu.org/mailman/options/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.nongnu.org/archive/html/qemu-devel>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <https://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: Peter Maydell <peter.maydell@linaro.org>
Cc: Nicholas Thomas <nick@bytemark.co.uk>, qemu-devel@nongnu.org, Juan Quintela <quintela@redhat.com>

On Tue, May 21, 2013 at 10:16:48PM +0100, Peter Maydell wrote:
> On 21 May 2013 21:43, mdroth <mdroth@linux.vnet.ibm.com> wrote:
> > Makes sense, but apparently version IDs for incoming device state are
> > not allowed to exceed the destination's version, so we can't bump it
> > beyond the value in 1.5 without breaking migration from 1.5+ -> 1.5
> 
> We care about backwards migration? That sounds like a pain.

As a best effort at least, hence subsections and whatnot, but not
always. This case for instance...

> 
> > So I think our only option for version ID is to lock in the 1.5 value,
> > which seems to be 1936 (hopefully that's consistent across builds...).
> 
> Yeah, I'm not convinced that's going to be consistent across builds,
> compilers, 64 vs 32 bit, etc etc etc. That's why I suggested a really
> high number.

Yah, it's more important to ensure old->new. Playing guessing games
about struct sizes to try to maintain new->old is likely to conflict
with that, so I guess we don't have much choice here. I'll send a patch
out shortly.

> 
> thanks
> -- PMM
>