From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:41277) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TjMJW-0006ey-2Y for qemu-devel@nongnu.org; Thu, 13 Dec 2012 22:51:56 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1TjMJU-0008Qz-Bu for qemu-devel@nongnu.org; Thu, 13 Dec 2012 22:51:54 -0500 Received: from ozlabs.org ([203.10.76.45]:56219) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TjMJU-0008Nd-1n for qemu-devel@nongnu.org; Thu, 13 Dec 2012 22:51:52 -0500 From: Rusty Russell In-Reply-To: <87y5h5xvbk.fsf@codemonkey.ws> 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> <87y5h5xvbk.fsf@codemonkey.ws> Date: Fri, 14 Dec 2012 11:27:02 +1030 Message-ID: <87bodx4fj5.fsf@rustcorp.com.au> 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: Anthony Liguori , qemu-devel@nongnu.org Cc: David Gibson , "Michael S. Tsirkin" Anthony Liguori writes: > 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... My transition was to copy that structure to VirtQueueSavedElement, and it's only used for loading old versions. With the new code we only need the head from that structure. > 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 :-) What is the rule about new versions? Can we introduce a new save version at any time, or only at major qemu version changes? Thanks, Rusty.