From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from eggs.gnu.org ([2001:4830:134:3::10]:38026)
	by lists.gnu.org with esmtp (Exim 4.71)
	(envelope-from <mst@redhat.com>) id 1Wv1RJ-0006MD-E4
	for qemu-devel@nongnu.org; Thu, 12 Jun 2014 05:37:03 -0400
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
	(envelope-from <mst@redhat.com>) id 1Wv1RD-00014Q-5Y
	for qemu-devel@nongnu.org; Thu, 12 Jun 2014 05:36:57 -0400
Received: from mx1.redhat.com ([209.132.183.28]:19584)
	by eggs.gnu.org with esmtp (Exim 4.71)
	(envelope-from <mst@redhat.com>) id 1Wv1RC-00012W-Sx
	for qemu-devel@nongnu.org; Thu, 12 Jun 2014 05:36:51 -0400
Date: Thu, 12 Jun 2014 12:37:12 +0300
From: "Michael S. Tsirkin" <mst@redhat.com>
Message-ID: <20140612093712.GA22565@redhat.com>
References: <20140514154130.10746.1412.stgit@bahia.local>
	<20140514154230.10746.56297.stgit@bahia.local>
	<5384A8D2.8050104@redhat.com> <20140529111253.4ff55199@bahia.local>
	<538708FA.4070309@redhat.com> <20140612094351.6295fd38@bahia.local>
	<53996B0E.4040808@redhat.com> <20140612110601.3fe5626e@bahia.local>
	<539970B3.3040304@redhat.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <539970B3.3040304@redhat.com>
Subject: Re: [Qemu-devel] [PATCH RFC 8/8] virtio: add endian-ambivalent
 support to VirtIODevice
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: Paolo Bonzini <pbonzini@redhat.com>
Cc: Kevin Wolf <kwolf@redhat.com>, Fam Zheng <famz@redhat.com>, Stefan Hajnoczi <stefanha@redhat.com>, Juan Quintela <quintela@redhat.com>, Alexander Graf <agraf@suse.de>, qemu-devel@nongnu.org, Anthony Liguori <aliguori@amazon.com>, Amit Shah <amit.shah@redhat.com>, Andreas =?iso-8859-1?Q?F=E4rber?= <afaerber@suse.de>, Greg Kurz <gkurz@linux.vnet.ibm.com>

On Thu, Jun 12, 2014 at 11:19:47AM +0200, Paolo Bonzini wrote:
> Il 12/06/2014 11:06, Greg Kurz ha scritto:
> >On Thu, 12 Jun 2014 10:55:42 +0200
> >Paolo Bonzini <pbonzini@redhat.com> wrote:
> >
> >>Il 12/06/2014 09:43, Greg Kurz ha scritto:
> >>>Since we know that 0 < max_nr_ports < 32,  is it acceptable to guess
> >>>the correct endianness with a heuristic ?
> >>>
> >>>if (max_nr_ports > tswap32(s->config.max_nr_ports)) {
> >>>	max_nr_ports = bswap32(max_nr_ports);
> >>>}
> >>>
> >>>if (max_nr_ports > tswap32(s->config.max_nr_ports)) {
> >>>	return -EINVAL;
> >>>}
> >>
> >>Yes, I guess it is acceptable.  So first you should fix the code to
> >>always serialize fields as big-endian, and then apply this little hack
> >>and virtio_tswap on top of the previous change.
> >
> >BTW, can someone explain why we stream the device config ?
> 
> For max_nr_ports it is useless indeed.  Let's keep storing it for backwards
> compatibility, but you can remove its load.
> 
> The cols and rows values should be defined by the host and thus could even
> change on migration, there is no need to store them.  As of now, however,
> they are unused in QEMU and should always be zero, because
> VIRTIO_CONSOLE_F_SIZE is not supported.
> 
> Paolo

Maybe just drop unnecessary stuff for new machine types?
Then we won't need hacks to migrate it.

-- 
MST