From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:50979) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZMpbm-00089N-Re for qemu-devel@nongnu.org; Tue, 04 Aug 2015 23:43:15 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZMpbh-0007KP-Kf for qemu-devel@nongnu.org; Tue, 04 Aug 2015 23:43:14 -0400 Received: from e28smtp03.in.ibm.com ([122.248.162.3]:34145) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZMpbg-0007FC-VN for qemu-devel@nongnu.org; Tue, 04 Aug 2015 23:43:09 -0400 Received: from /spool/local by e28smtp03.in.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Wed, 5 Aug 2015 09:13:03 +0530 Date: Wed, 5 Aug 2015 09:12:54 +0530 From: Bharata B Rao Message-ID: <20150805034254.GA23976@in.ibm.com> References: <1438580143-587-1-git-send-email-bharata@linux.vnet.ibm.com> <1438580143-587-4-git-send-email-bharata@linux.vnet.ibm.com> <55C0CD54.7090108@linux.vnet.ibm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <55C0CD54.7090108@linux.vnet.ibm.com> Subject: Re: [Qemu-devel] [RFC PATCH v0 3/5] spapr: Revert to memory@XXXX representation for non-hotplugged memory Reply-To: bharata@linux.vnet.ibm.com List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Nathan Fontenot Cc: mdroth@linux.vnet.ibm.com, agraf@suse.de, qemu-ppc@nongnu.org, qemu-devel@nongnu.org, david@gibson.dropbear.id.au On Tue, Aug 04, 2015 at 09:33:56AM -0500, Nathan Fontenot wrote: > On 08/03/2015 12:35 AM, Bharata B Rao wrote: > > Don't represent non-hotluggable memory under drconf node. With this > > we don't have to create DRC objects for them. > > > > The effect of this patch is that we revert back to memory@XXXX representation > > for all the memory specified with -m option and represent the cold > > plugged memory and hot-pluggable memory under > > ibm,dynamic-reconfiguration-memory. > > > > I was looking through this and looking at the kernel code that inits memory > for power systems and I wanted to make sure this is really working and > you are seeing all the memory you expect to see in the guest. > > Looking through the memory init code (powerpc/kerne/prom.c) it appears that > the additional memory@XXX would get initialized very early in boot, the same > time we currently init the memory@0 node. Then later in boot we would init > the rest of memory, lmbs in the dynamic-reconfiguration property. > > Just wanting to make sure I'm understanding how this is working. > > Also, since the memory specified in the memory@XXX nodes is not removable this > should not break any of the userspace tools. Thanks for confirming this. Initially I went for only memory@0 and rest of the memory as part of ibm,dynamic-reconfiguration-memory because that's how it was in a couple of PowerVM boxes that I checked. Regards, Bharata.