From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:43576) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XrSLm-0001fL-Bs for qemu-devel@nongnu.org; Thu, 20 Nov 2014 09:04:52 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XrSLg-0004le-6x for qemu-devel@nongnu.org; Thu, 20 Nov 2014 09:04:46 -0500 Received: from mx1.redhat.com ([209.132.183.28]:38629) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XrSLf-0004lY-Vo for qemu-devel@nongnu.org; Thu, 20 Nov 2014 09:04:40 -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 sAKE4d1Z017847 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL) for ; Thu, 20 Nov 2014 09:04:39 -0500 Date: Thu, 20 Nov 2014 16:04:36 +0200 From: "Michael S. Tsirkin" Message-ID: <20141120140436.GA5843@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> <87oas2yoz1.fsf@blackfin.pond.sub.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <87oas2yoz1.fsf@blackfin.pond.sub.org> 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: Markus Armbruster Cc: Paolo Bonzini , Juan Quintela , qemu-devel@nongnu.org, dgilbert@redhat.com On Thu, Nov 20, 2014 at 02:35:14PM +0100, Markus Armbruster wrote: > What am I missing here that can justify the complexity of partially > overriding target configuration in the migration stream plus > infrastructure for resizing memory? The justification is that sizing it properly is an unsolved problem. The difference with real hardware is that size of the flash depends dynamically on the machine configuration. And it's drastic: you can have from 1 to 256 CPUs, 0 to 256 PCI bridges on each root, etc. And I do believe the infrastructure will be handy for other things. For example, boot order ROM is now dynamic too, with enough bootable devices it will start overflowing a page and then we will have the same problem. And the patchset is all of 150 lines with comments, the point is that everything follows the same path: it's enough to test one cross-version migration, e.g. 2.1->2.3 or whatever, to make sure resizing works properly. Unlike extra modes which need testing of each machine type with each guest. -- MST