From: David Gibson <david@gibson.dropbear.id.au>
To: Bharata B Rao <bharata@linux.vnet.ibm.com>
Cc: mdroth@linux.vnet.ibm.com, aik@ozlabs.ru, agraf@suse.de,
qemu-devel@nongnu.org, qemu-ppc@nongnu.org,
tyreld@linux.vnet.ibm.com, nfont@linux.vnet.ibm.com,
imammedo@redhat.com
Subject: Re: [Qemu-devel] [RFC PATCH v4 3/5] spapr: Support ibm, dynamic-reconfiguration-memory
Date: Wed, 24 Jun 2015 15:55:08 +1000 [thread overview]
Message-ID: <20150624055508.GB10837@voom.redhat.com> (raw)
In-Reply-To: <20150624022544.GD26051@in.ibm.com>
[-- Attachment #1: Type: text/plain, Size: 5298 bytes --]
On Wed, Jun 24, 2015 at 07:55:44AM +0530, Bharata B Rao wrote:
> On Tue, Jun 23, 2015 at 11:54:29AM +1000, David Gibson wrote:
> > On Fri, Jun 19, 2015 at 03:47:55PM +0530, Bharata B Rao wrote:
> > > Parse ibm,architecture.vec table obtained from the guest and enable
> > > memory node configuration via ibm,dynamic-reconfiguration-memory if guest
> > > supports it. This is in preparation to support memory hotplug for
> > > sPAPR guests.
> > >
> > > This changes the way memory node configuration is done. Currently all
> > > memory nodes are built upfront. But after this patch, only memory@0 node
> > > for RMA is built upfront. Guest kernel boots with just that and rest of
> > > the memory nodes (via memory@XXX or ibm,dynamic-reconfiguration-memory)
> > > are built when guest does ibm,client-architecture-support call.
> > >
> > > Note: This patch needs a SLOF enhancement which is already part of
> > > SLOF binary in QEMU.
> > >
> > > Signed-off-by: Bharata B Rao <bharata@linux.vnet.ibm.com>
> >
> > [snip]
> > > +int spapr_h_cas_compose_response(sPAPRMachineState *spapr,
> > > + target_ulong addr, target_ulong size,
> > > + bool cpu_update, bool memory_update)
> > > +{
> > > + void *fdt, *fdt_skel;
> > > + sPAPRDeviceTreeUpdateHeader hdr = { .version_id = 1 };
> > > +
> > > + size -= sizeof(hdr);
> > > +
> > > + /* Create sceleton */
> > > + fdt_skel = g_malloc0(size);
> > > + _FDT((fdt_create(fdt_skel, size)));
> > > + _FDT((fdt_begin_node(fdt_skel, "")));
> > > + _FDT((fdt_end_node(fdt_skel)));
> > > + _FDT((fdt_finish(fdt_skel)));
> > > + fdt = g_malloc0(size);
> > > + _FDT((fdt_open_into(fdt_skel, fdt, size)));
> > > + g_free(fdt_skel);
> > > +
> > > + /* Fixup cpu nodes */
> > > + if (cpu_update) {
> > > + _FDT((spapr_fixup_cpu_dt(fdt, spapr)));
> > > + }
> >
> > The cpu_update parameter seems like its not related to memory hotplug
> > at all. I'm guessing it relates to CPU hotplug, in which case please
> > defer it until those patches are ready to go.
>
> This change isn't related to cpu hotplug. Earlier this compose response
> routine only did CPU device tree fixup based on some conditions. I have
> enabled it to check for availability DRCONF_MEMORY feature and accordingly
> fixup memory DT. So this change just checks if cpu fixup is necessary
> or not. Essentially we aren't changing any behaviour wrt cpu dt
> fixup here.
Hm, ok. Would there be any problem with just unconditionally doing
both fixups? This is about as far from a hot path as its possible to
get.
>
> >
> > > +
> > > + /* Generate memory nodes or ibm,dynamic-reconfiguration-memory node */
> > > + if (memory_update && spapr->dr_lmb_enabled) {
> > > + _FDT((spapr_populate_drconf_memory(spapr, fdt)));
> > > + } else {
> > > + _FDT((spapr_populate_memory(spapr, fdt)));
> > > + }
> > > +
> > > + /* Pack resulting tree */
> > > + _FDT((fdt_pack(fdt)));
> > > +
> > > + if (fdt_totalsize(fdt) + sizeof(hdr) > size) {
> > > + trace_spapr_cas_failed(size);
> > > + return -1;
> > > + }
> > > +
> > > + cpu_physical_memory_write(addr, &hdr, sizeof(hdr));
> > > + cpu_physical_memory_write(addr + sizeof(hdr), fdt, fdt_totalsize(fdt));
> > > + trace_spapr_cas_continue(fdt_totalsize(fdt) + sizeof(hdr));
> > > + g_free(fdt);
> > > +
> > > + return 0;
> > > +}
> > > +
> > > static void spapr_finalize_fdt(sPAPRMachineState *spapr,
> > > hwaddr fdt_addr,
> > > hwaddr rtas_addr,
> > > @@ -756,10 +866,16 @@ static void spapr_finalize_fdt(sPAPRMachineState *spapr,
> > > /* open out the base tree into a temp buffer for the final tweaks */
> > > _FDT((fdt_open_into(spapr->fdt_skel, fdt, FDT_MAX_SIZE)));
> > >
> > > - ret = spapr_populate_memory(spapr, fdt);
> > > - if (ret < 0) {
> > > - fprintf(stderr, "couldn't setup memory nodes in fdt\n");
> > > - exit(1);
> > > + /*
> > > + * Add memory@0 node to represent RMA. Rest of the memory is either
> > > + * represented by memory nodes or ibm,dynamic-reconfiguration-memory
> > > + * node later during ibm,client-architecture-support call.
> > > + */
> > > + for (i = 0; i < nb_numa_nodes; ++i) {
> > > + if (numa_info[i].node_mem) {
> > > + spapr_populate_memory_node(fdt, i, 0, spapr->rma_size);
> > > + break;
> > > + }
> >
> > ?? The code doesn't seem to match the comment - you appear to be
> > creating a memory@0 node for every NUMA node, not just for the RMA,
> > which doesn't make much sense.
>
> I have a break there to ensure memory@0 is created only once from the 1st
> memory-less node. I am slightly changing this in next version to ensure
> that this works correctly even when -numa isn't specified.
Ah, sorry, I missed the break;. That should be ok then.
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
[-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --]
next prev parent reply other threads:[~2015-06-24 5:54 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-06-19 10:17 [Qemu-devel] [RFC PATCH v4 0/5] Memory hotplug for PowerPC sPAPR guests Bharata B Rao
2015-06-19 10:17 ` [Qemu-devel] [RFC PATCH v4 1/5] spapr: Initialize hotplug memory address space Bharata B Rao
2015-06-23 1:33 ` David Gibson
2015-06-24 2:14 ` Bharata B Rao
2015-06-19 10:17 ` [Qemu-devel] [RFC PATCH v4 2/5] spapr: Add LMB DR connectors Bharata B Rao
2015-06-23 1:32 ` David Gibson
2015-06-24 2:19 ` Bharata B Rao
2015-06-24 3:24 ` Bharata B Rao
2015-06-24 5:51 ` David Gibson
2015-06-25 12:56 ` Michael Roth
2015-06-19 10:17 ` [Qemu-devel] [RFC PATCH v4 3/5] spapr: Support ibm, dynamic-reconfiguration-memory Bharata B Rao
2015-06-23 1:54 ` David Gibson
2015-06-24 2:25 ` Bharata B Rao
2015-06-24 5:55 ` David Gibson [this message]
2015-06-25 6:17 ` Bharata B Rao
2015-06-19 10:17 ` [Qemu-devel] [RFC PATCH v4 4/5] spapr: Make hash table size a factor of maxram_size Bharata B Rao
2015-06-23 2:08 ` David Gibson
2015-06-19 10:17 ` [Qemu-devel] [RFC PATCH v4 5/5] spapr: Memory hotplug support Bharata B Rao
2015-06-23 2:29 ` David Gibson
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=20150624055508.GB10837@voom.redhat.com \
--to=david@gibson.dropbear.id.au \
--cc=agraf@suse.de \
--cc=aik@ozlabs.ru \
--cc=bharata@linux.vnet.ibm.com \
--cc=imammedo@redhat.com \
--cc=mdroth@linux.vnet.ibm.com \
--cc=nfont@linux.vnet.ibm.com \
--cc=qemu-devel@nongnu.org \
--cc=qemu-ppc@nongnu.org \
--cc=tyreld@linux.vnet.ibm.com \
/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).