From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:60903) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Xr2qN-00073u-Bp for qemu-devel@nongnu.org; Wed, 19 Nov 2014 05:50:45 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Xr2qG-0005i8-QU for qemu-devel@nongnu.org; Wed, 19 Nov 2014 05:50:39 -0500 Received: from mx1.redhat.com ([209.132.183.28]:56989) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Xr2qG-0005hw-Cd for qemu-devel@nongnu.org; Wed, 19 Nov 2014 05:50:32 -0500 Received: from int-mx14.intmail.prod.int.phx2.redhat.com (int-mx14.intmail.prod.int.phx2.redhat.com [10.5.11.27]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id sAJAoUne023239 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL) for ; Wed, 19 Nov 2014 05:50:30 -0500 From: Juan Quintela In-Reply-To: <20141119103038.GD26395@redhat.com> (Michael S. Tsirkin's message of "Wed, 19 Nov 2014 12:30:38 +0200") References: <1416254843-16859-1-git-send-email-mst@redhat.com> <1416254843-16859-3-git-send-email-mst@redhat.com> <546AE14E.7060606@redhat.com> <20141118074904.GA19745@redhat.com> <87y4r7o8dh.fsf@elfo.elfo> <20141119093320.GA26119@redhat.com> <87tx1v336u.fsf@blackfin.pond.sub.org> <20141119103038.GD26395@redhat.com> Date: Wed, 19 Nov 2014 11:50:28 +0100 Message-ID: <874mtvo45n.fsf@elfo.elfo> MIME-Version: 1.0 Content-Type: text/plain Subject: Re: [Qemu-devel] [PATCH 2/5] exec: qemu_ram_alloc_device, qemu_ram_resize Reply-To: quintela@redhat.com List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: "Michael S. Tsirkin" Cc: Paolo Bonzini , Markus Armbruster , dgilbert@redhat.com, qemu-devel@nongnu.org "Michael S. Tsirkin" wrote: > On Wed, Nov 19, 2014 at 11:16:57AM +0100, Markus Armbruster wrote: >> "Michael S. Tsirkin" writes: >> Since migration doesn't transport configuration, we require a compatibly >> configured target, and that includes identical memory sizes. RAM size >> is explicit and the user's problem. ROM size is generally implicit, and >> we use machine type compatibility machinery to keep it fixed. BIOS >> changes can break migration only when we screw up or forget the >> compatibility machinery. Same as for lots of other stuff. No big deal, >> really, just a consequence of not migrating configuration. > > You don't get to maintain it, so it's no big deal for you. > > I see pain every single release and code is becoming spaghetty-like very > quickly. We thought it would work. It does not. We do need a solution. > > And the pain is completely self-inflicted: we already migrate > all necessary information! > It's just a question of adjusting our datastructures to it. migration from version foo to version bar. You have two options here: - You make source (foo) send the data on the format/sizes that destination (bar) wants. - You make destination (bar) handle whatever source (foo) sends. You need to put the "spagueti code" in foo or bar. It needs to be in one of the two places, because if that code was not needed, we would not be discussion here, see? So, what we are discussing is where is better to put this code. Emit the code that destination expects, or make destination handle whatever is sent. Amound of mangling need to be basically the same. Later, Juan.