From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:43712) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Xr5RV-0002Rq-BS for qemu-devel@nongnu.org; Wed, 19 Nov 2014 08:37:15 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Xr5RP-0005Be-7G for qemu-devel@nongnu.org; Wed, 19 Nov 2014 08:37:09 -0500 Received: from mx1.redhat.com ([209.132.183.28]:51508) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Xr5RO-0005Ba-VB for qemu-devel@nongnu.org; Wed, 19 Nov 2014 08:37:03 -0500 Received: from int-mx09.intmail.prod.int.phx2.redhat.com (int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id sAJDb21K002189 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL) for ; Wed, 19 Nov 2014 08:37:02 -0500 Date: Wed, 19 Nov 2014 15:36:59 +0200 From: "Michael S. Tsirkin" Message-ID: <20141119133659.GA27488@redhat.com> 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> <874mtvo45n.fsf@elfo.elfo> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <874mtvo45n.fsf@elfo.elfo> Subject: Re: [Qemu-devel] [PATCH 2/5] exec: qemu_ram_alloc_device, qemu_ram_resize List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Juan Quintela Cc: Paolo Bonzini , Markus Armbruster , dgilbert@redhat.com, qemu-devel@nongnu.org On Wed, Nov 19, 2014 at 11:50:28AM +0100, Juan Quintela wrote: > "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. This is not what the patch does at all. There is no special-casing depending on machine type anywhere. Please review the code and respond to actual patches. -- MST