From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:45550) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TiE6t-0006dg-Tv for qemu-devel@nongnu.org; Mon, 10 Dec 2012 19:54:13 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1TiE6s-0004sU-Gp for qemu-devel@nongnu.org; Mon, 10 Dec 2012 19:54:11 -0500 Received: from mail-ye0-f173.google.com ([209.85.213.173]:48491) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TiE6s-0004sL-D5 for qemu-devel@nongnu.org; Mon, 10 Dec 2012 19:54:10 -0500 Received: by mail-ye0-f173.google.com with SMTP id l5so646690yen.4 for ; Mon, 10 Dec 2012 16:54:09 -0800 (PST) From: Anthony Liguori In-Reply-To: <87d2yhcttd.fsf@rustcorp.com.au> References: <1355149790-8125-1-git-send-email-aliguori@us.ibm.com> <1355149790-8125-4-git-send-email-aliguori@us.ibm.com> <87d2yhcttd.fsf@rustcorp.com.au> Date: Mon, 10 Dec 2012 18:54:07 -0600 Message-ID: <87y5h5xvbk.fsf@codemonkey.ws> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: Re: [Qemu-devel] [PATCH 3/4] virtio: modify savevm to have a stable wire format List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Rusty Russell , qemu-devel@nongnu.org Cc: David Gibson , "Michael S. Tsirkin" Rusty Russell writes: > Anthony Liguori writes: >> We were memcpy()'ing a structure to the wire :-/ Since savevm really >> only works on x86 today, lets just declare that this element is sent >> over the wire as a little endian value in order to fix the bitness. >> >> Unfortunately, we also send raw pointers and size_t which are going >> to be different values on a 32-bit vs. 64-bit QEMU so we need to also >> deal with that case. >> >> A lot of values that should have been previously ignored are now sent >> as 0 and ignored on the receive side too. > > Don't we want to transition to vmstate anyway? Can we just do that, and > relegate the existing slightly broken code, to legacy? What worries me is if someone changes VirtQueueElement, then all the sudden migration breaks. By transitioning to what I've sent, we at least have a better documented protocol that isn't prone to subtle breakage anymore. Plus, we resolve the endian issue before it becomes a bigger problem when David actually gets live migration working reliably on PPC... I'm certainly in favor of cleaning up the savevm format and probably leaving the existing load/save functions as-is for legacy purposes. I'll leave that as an exercise for someone else though :-) Regards, Anthony Liguori > > Cheers, > Rusty.