From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from eggs.gnu.org ([208.118.235.92]:39579)
	by lists.gnu.org with esmtp (Exim 4.71)
	(envelope-from <stefanha@gmail.com>) id 1TiLuK-0004nF-5P
	for qemu-devel@nongnu.org; Tue, 11 Dec 2012 04:13:50 -0500
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
	(envelope-from <stefanha@gmail.com>) id 1TiLjD-0008T7-GL
	for qemu-devel@nongnu.org; Tue, 11 Dec 2012 04:03:17 -0500
Received: from mail-wi0-f177.google.com ([209.85.212.177]:55310)
	by eggs.gnu.org with esmtp (Exim 4.71)
	(envelope-from <stefanha@gmail.com>) id 1TiLjD-0008T2-5R
	for qemu-devel@nongnu.org; Tue, 11 Dec 2012 04:02:15 -0500
Received: by mail-wi0-f177.google.com with SMTP id hm2so1601591wib.10
	for <qemu-devel@nongnu.org>; Tue, 11 Dec 2012 01:02:14 -0800 (PST)
Date: Tue, 11 Dec 2012 10:02:10 +0100
From: Stefan Hajnoczi <stefanha@gmail.com>
Message-ID: <20121211090210.GD23720@stefanha-thinkpad.muc.redhat.com>
References: <1355149790-8125-1-git-send-email-aliguori@us.ibm.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <1355149790-8125-1-git-send-email-aliguori@us.ibm.com>
Subject: Re: [Qemu-devel] [RFC 0/4] virtio: stabilize migration format
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: Anthony Liguori <aliguori@us.ibm.com>
Cc: Rusty Russell <rusty@rustcorp.com.au>, "Michael S. Tsirkin" <mst@redhat.com>, qemu-devel@nongnu.org, David Gibson <david@gibson.dropbear.id.au>

On Mon, Dec 10, 2012 at 08:29:46AM -0600, Anthony Liguori wrote:
> This series replaces:
> 
>     qemu_put_buffer(f, (unsigned char*)&req->elem, sizeof(req->elem));
> 
> With code that properly saves out each element of the structure using
> a well defined endian format.  Migration is broken today from big endian to
> little endian hosts.
> 
> There's no way to fix this problem without bumping the migration version
> number and that's exactly what we do here.  By bumping the migration version
> number, we do break new->old migration but that's unavoidable right now.
> 
> In order to support old->new, we assume that all incoming data is in little
> endian.  The final patch adds a check to the load routines to fail old->new
> on big endian hosts where this may not have been true.

Is there a way to detect the endianness of the source host - by peaking
at a known multibyte value in the incoming stream?

That way we could even support cross-endian migration.

Not sure if this much magic makes sense since cross-endian migration is
probably used rarely.

Stefan