From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from eggs.gnu.org ([208.118.235.92]:52786)
	by lists.gnu.org with esmtp (Exim 4.71)
	(envelope-from <peter.maydell@linaro.org>) id 1Uetvm-0005dZ-29
	for qemu-devel@nongnu.org; Tue, 21 May 2013 17:17:19 -0400
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
	(envelope-from <peter.maydell@linaro.org>) id 1Uetvh-0001r4-I4
	for qemu-devel@nongnu.org; Tue, 21 May 2013 17:17:13 -0400
Received: from mail-lb0-f180.google.com ([209.85.217.180]:44399)
	by eggs.gnu.org with esmtp (Exim 4.71)
	(envelope-from <peter.maydell@linaro.org>) id 1Uetvh-0001qw-Bg
	for qemu-devel@nongnu.org; Tue, 21 May 2013 17:17:09 -0400
Received: by mail-lb0-f180.google.com with SMTP id r10so1329456lbi.39
	for <qemu-devel@nongnu.org>; Tue, 21 May 2013 14:17:08 -0700 (PDT)
MIME-Version: 1.0
In-Reply-To: <20130521204338.GG2441@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>
From: Peter Maydell <peter.maydell@linaro.org>
Date: Tue, 21 May 2013 22:16:48 +0100
Message-ID: <CAFEAcA8_y_MbswkamHOge8b3nhM_S_6wo5CpOfi3pwZPGdEJzw@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8
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: mdroth <mdroth@linux.vnet.ibm.com>
Cc: Juan Quintela <quintela@redhat.com>, qemu-devel@nongnu.org, Nicholas Thomas <nick@bytemark.co.uk>

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.

> 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.

thanks
-- PMM