From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:46444) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Xsu0J-0005O9-MG for qemu-devel@nongnu.org; Mon, 24 Nov 2014 08:48:41 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Xsu0C-0002ep-Rr for qemu-devel@nongnu.org; Mon, 24 Nov 2014 08:48:35 -0500 Received: from mx1.redhat.com ([209.132.183.28]:59485) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Xsu0C-0002eL-Iz for qemu-devel@nongnu.org; Mon, 24 Nov 2014 08:48:28 -0500 Received: from int-mx10.intmail.prod.int.phx2.redhat.com (int-mx10.intmail.prod.int.phx2.redhat.com [10.5.11.23]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id sAODmRVn010636 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL) for ; Mon, 24 Nov 2014 08:48:27 -0500 Message-ID: <54733726.6080406@redhat.com> Date: Mon, 24 Nov 2014 14:48:22 +0100 From: Paolo Bonzini MIME-Version: 1.0 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> <20141120140436.GA5843@redhat.com> In-Reply-To: <20141120140436.GA5843@redhat.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit 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: "Michael S. Tsirkin" , Markus Armbruster Cc: Juan Quintela , qemu-devel@nongnu.org, dgilbert@redhat.com On 20/11/2014 15:04, Michael S. Tsirkin wrote: > 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. Not really: sizing it properly is a tedious thing to do, but it is not a problem at all. We _almost_ get it right, only the DSDT can change from one version to the next right now. And patches exist to pad the DSDT adequately; those patches are simpler than these ones. I am okay with considering it "too tedious to spend more time on it", especially because the size of the ACPI tables already changed arbitrarily from one version to the other when it was computed in the firmware. On the other hand, one could also say that being able to size tables properly is an _advantage_ of doing tables in QEMU. I was expecting little opposition and thus thinking it was not worthwhile to discuss the approach to take. Apparently there _is_ opposition, so I think we should reconsider my patches. Paolo