From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:35614) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Z2wYm-0001mC-FS for qemu-devel@nongnu.org; Thu, 11 Jun 2015 03:05:57 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Z2wYc-0002gM-Ut for qemu-devel@nongnu.org; Thu, 11 Jun 2015 03:05:56 -0400 Received: from e23smtp05.au.ibm.com ([202.81.31.147]:33876) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Z2wYc-0002dq-Au for qemu-devel@nongnu.org; Thu, 11 Jun 2015 03:05:46 -0400 Received: from /spool/local by e23smtp05.au.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Thu, 11 Jun 2015 17:05:40 +1000 Received: from d23relay07.au.ibm.com (d23relay07.au.ibm.com [9.190.26.37]) by d23dlp03.au.ibm.com (Postfix) with ESMTP id AA3F43578052 for ; Thu, 11 Jun 2015 17:05:37 +1000 (EST) Received: from d23av03.au.ibm.com (d23av03.au.ibm.com [9.190.234.97]) by d23relay07.au.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id t5B75S1458851572 for ; Thu, 11 Jun 2015 17:05:38 +1000 Received: from d23av03.au.ibm.com (localhost [127.0.0.1]) by d23av03.au.ibm.com (8.14.4/8.14.4/NCO v10.0 AVout) with ESMTP id t5B754SW032383 for ; Thu, 11 Jun 2015 17:05:04 +1000 Date: Thu, 11 Jun 2015 12:34:44 +0530 From: Bharata B Rao Message-ID: <20150611070444.GA29771@in.ibm.com> References: <20150525074757.GE32383@in.ibm.com> <20150525174240.GP17796@thinpad.lan.raisama.net> <20150608055818.GE25832@in.ibm.com> <20150608115103.3f888b1e@nial.brq.redhat.com> <20150608155139.GL3410@thinpad.lan.raisama.net> <20150609112319.67bb7312@nial.brq.redhat.com> <20150609124054.GR3410@thinpad.lan.raisama.net> <20150610114319.6d97bedc@nial.brq.redhat.com> <20150610125053.GH9812@in.ibm.com> <20150611085603.7a6b8acd@nial.brq.redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20150611085603.7a6b8acd@nial.brq.redhat.com> Subject: Re: [Qemu-devel] [RFC PATCH v0] numa: API to lookup NUMA node by address Reply-To: bharata@linux.vnet.ibm.com List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Igor Mammedov Cc: qemu-devel@nongnu.org, Paolo Bonzini , Eduardo Habkost , david@gibson.dropbear.id.au On Thu, Jun 11, 2015 at 08:56:03AM +0200, Igor Mammedov wrote: > > > > And to make this work, it needs to be aware of NUMA information for > > > > hotplugged memory too. > > > I've checked spapr_populate_drconf_memory() from original series, > > > it needs to be aware at startup about address ranges -> node mapping > > > including mapping partitioning of whole hotplug memory range > > > (i.e. not actual hotplugged memory). > > > -numa node_mem & numa_set_mem_node_id() are sufficient for this purpose > > > > spapr_populate_drconf_memory() needs to know about node information for > > boot time memory as well as the hotplugged pc-dimm memory. Since chunks > > of hotplug memory range could be plugged into any node, we need to > > be able to locate the node id for such memory range. This is where > > numa_set_mem_node_id() call for each realized dimm will help. > So you are saying that spapr_populate_drconf_memory() doesn't need to know > in advance about unplugged memory ranges and could be updated at runtime. > (I've thought that device tree is build only at boot and guest can't > accept dynamic updates to it, therefore you'd need provide addr -> node_id > mapping at boot time including for not yet plugged memory). Here are we dynamically adding a device tree node at runtime when guest issues ibm,architecture-client-support call during early boot. Guest firmware (SLOF) has already been updated to support such dynamic update. During hotplug the node id information is also updated in ibm,dynamic-memory property that is present under this device tree node. Regards, Bharata.