From: Bharata B Rao <bharata@linux.vnet.ibm.com>
To: Igor Mammedov <imammedo@redhat.com>
Cc: qemu-devel@nongnu.org, Paolo Bonzini <pbonzini@redhat.com>,
Eduardo Habkost <ehabkost@redhat.com>,
david@gibson.dropbear.id.au
Subject: Re: [Qemu-devel] [RFC PATCH v0] numa: API to lookup NUMA node by address
Date: Thu, 11 Jun 2015 12:34:44 +0530 [thread overview]
Message-ID: <20150611070444.GA29771@in.ibm.com> (raw)
In-Reply-To: <20150611085603.7a6b8acd@nial.brq.redhat.com>
On Thu, Jun 11, 2015 at 08:56:03AM +0200, Igor Mammedov wrote:
<snip>
> > > > 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.
prev parent reply other threads:[~2015-06-11 7:05 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-05-07 7:04 [Qemu-devel] [RFC PATCH v0] numa: API to lookup NUMA node by address Bharata B Rao
2015-05-13 15:33 ` Bharata B Rao
2015-05-13 18:06 ` Eduardo Habkost
2015-05-14 9:39 ` Paolo Bonzini
2015-05-25 7:47 ` Bharata B Rao
2015-05-25 17:42 ` Eduardo Habkost
2015-06-08 5:58 ` Bharata B Rao
2015-06-08 9:51 ` Igor Mammedov
2015-06-08 15:51 ` Eduardo Habkost
2015-06-08 15:55 ` Paolo Bonzini
2015-06-08 16:09 ` Eduardo Habkost
2015-06-09 9:23 ` Igor Mammedov
2015-06-09 12:40 ` Eduardo Habkost
2015-06-10 9:43 ` Igor Mammedov
2015-06-10 12:14 ` Eduardo Habkost
2015-06-10 12:50 ` Bharata B Rao
2015-06-11 6:56 ` Igor Mammedov
2015-06-11 7:04 ` Bharata B Rao [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20150611070444.GA29771@in.ibm.com \
--to=bharata@linux.vnet.ibm.com \
--cc=david@gibson.dropbear.id.au \
--cc=ehabkost@redhat.com \
--cc=imammedo@redhat.com \
--cc=pbonzini@redhat.com \
--cc=qemu-devel@nongnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).