From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:54974) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VjWtS-0003Fg-W8 for qemu-devel@nongnu.org; Thu, 21 Nov 2013 11:14:19 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1VjWtO-0002pi-56 for qemu-devel@nongnu.org; Thu, 21 Nov 2013 11:14:14 -0500 Received: from mx1.redhat.com ([209.132.183.28]:27022) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VjWtN-0002pc-SW for qemu-devel@nongnu.org; Thu, 21 Nov 2013 11:14:10 -0500 Date: Thu, 21 Nov 2013 18:17:07 +0200 From: "Michael S. Tsirkin" Message-ID: <20131121161707.GA12403@redhat.com> References: <1385001528-12003-1-git-send-email-imammedo@redhat.com> <1385001528-12003-22-git-send-email-imammedo@redhat.com> <528D9EC8.5090307@cn.fujitsu.com> <528E14F8.2070204@suse.de> <20131121153453.1ce72399@nial.usersys.redhat.com> <528E3037.8080005@suse.de> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline In-Reply-To: <528E3037.8080005@suse.de> Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] [PATCH 21/27] pc: add memory hotplug 440fx machine List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Andreas =?iso-8859-1?Q?F=E4rber?= Cc: peter.maydell@linaro.org, mdroth@linux.vnet.ibm.com, stefanb@linux.vnet.ibm.com, hutao@cn.fujitsu.com, quintela@redhat.com, mjt@tls.msk.ru, armbru@redhat.com, qemu-devel@nongnu.org, vasilis.liaskovitis@profitbricks.com, chegu_vinod@hp.com, kraxel@redhat.com, aliguori@amazon.com, pbonzini@redhat.com, Igor Mammedov , marcel.a@redhat.com, lcapitulino@redhat.com, stefanha@redhat.com, Li Guang On Thu, Nov 21, 2013 at 05:09:27PM +0100, Andreas F=E4rber wrote: > Am 21.11.2013 15:34, schrieb Igor Mammedov: > > On Thu, 21 Nov 2013 15:13:12 +0100 > > Andreas F=E4rber wrote: > >> Am 21.11.2013 06:48, schrieb Li Guang: > >>> Why not give the memory that not be hot-added a chance to be placed= on > >>> one memory slot? > >> > >> Seconded, I believe I requested that on the previous version already. > > Because current initial memory allocation is a mess and this already > > large series would become even more large and intrusive, so far serie= s > > it relatively not intrusive and self contained. > >=20 > > I believe re-factoring of initial memory to use Dimm devices should b= e > > done later on top of infrastructure this series provides. >=20 > My problem with that is that that would be a semantically incompatible > modeling change. Yes but we are not merging this for 1.7, time enough to make changes before 1.8. > With your series we might have /machine/dimm.0/child[0] > be the first hot-plugged memory and once such a refactoring is done, > child[0] silently becomes -m and child[1] is the hot-added one. >=20 > So if we know that we want/need to change the infrastructure, why not > add a single patch (?) to allocate one additional object on the bus now= ? > Unless we actually write the code, we won't know whether there are some > incorrect hot-plug assumptions in the dimm code. >=20 > Andreas > --=20 > SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 N=FCrnberg, Germany > GF: Jeff Hawn, Jennifer Guild, Felix Imend=F6rffer; HRB 16746 AG N=FCrn= berg