Re: [Qemu-devel] [RFC PATCH v2] spapr: Support ibm, dynamic-memory-v2 property

[Bharata B Rao]

On Wed, Apr 11, 2018 at 02:45:58PM +1000, David Gibson wrote:
> On Mon, Apr 09, 2018 at 11:55:38AM +0530, Bharata B Rao wrote:
> > The new property ibm,dynamic-memory-v2 allows memory to be represented
> > in a more compact manner in device tree.
> > 
> > Signed-off-by: Bharata B Rao 
> > ---
> > v1: https://lists.nongnu.org/archive/html/qemu-devel/2018-03/msg01788.html
> > Changes in v1:
> > - Minor cleanups in the error paths
> > - Rebased on top of ppc-for-2.13
> > 
> >  docs/specs/ppc-spapr-hotplug.txt |  19 +++
> >  hw/ppc/spapr.c   | 257 
> > ---
> >  include/hw/ppc/spapr.h   |   1 +
> >  include/hw/ppc/spapr_ovec.h  |   1 +
> >  4 files changed, 233 insertions(+), 45 deletions(-)
> 
> 
> 
> > diff --git a/docs/specs/ppc-spapr-hotplug.txt 
> > b/docs/specs/ppc-spapr-hotplug.txt
> > index f57e2a09c6..cc7833108e 100644
> > --- a/docs/specs/ppc-spapr-hotplug.txt
> > +++ b/docs/specs/ppc-spapr-hotplug.txt
> > @@ -387,4 +387,23 @@ Each LMB list entry consists of the following elements:
> >  - A 32bit flags word. The bit at bit position 0x0008 defines whether
> >the LMB is assigned to the the partition as of boot time.
> >  
> > +ibm,dynamic-memory-v2
> > +
> > +This property describes the dynamically reconfigurable memory. This is
> > +an alternate and newer way to describe dyanamically reconfigurable memory.
> > +It is a property encoded array that has an integer N (the number of
> > +LMB set entries) followed by N LMB set entries. There is an LMB set entry
> > +for each sequential group of LMBs that share common attributes.
> > +
> > +Each LMB set entry consists of the following elements:
> > +
> > +- Number of sequential LMBs in the entry represented by a 32bit integer.
> > +- Logical address of the first LMB in the set encoded as a 64bit integer.
> > +- DRC index of the first LMB in the set.
> > +- Associativity list index that is used as an index into
> > +  ibm,associativity-lookup-arrays property described earlier. This
> > +  is used to retrieve the right associativity list to be used for all
> > +  the LMBs in this set.
> > +- A 32bit flags word that applies to all the LMBs in the set.
> > +
> >  [1] 
> > http://thread.gmane.org/gmane.linux.ports.ppc.embedded/75350/focus=106867
> > diff --git a/hw/ppc/spapr.c b/hw/ppc/spapr.c
> > index 3ffadd6ac7..4a24fac38c 100644
> > --- a/hw/ppc/spapr.c
> > +++ b/hw/ppc/spapr.c
> > @@ -669,63 +669,139 @@ static uint32_t 
> > spapr_pc_dimm_node(MemoryDeviceInfoList *list, ram_addr_t addr)
> >  return -1;
> >  }
> >  
> > -/*
> > - * Adds ibm,dynamic-reconfiguration-memory node.
> > - * Refer to docs/specs/ppc-spapr-hotplug.txt for the documentation
> > - * of this device tree node.
> > - */
> > -static int spapr_populate_drconf_memory(sPAPRMachineState *spapr, void 
> > *fdt)
> > +struct of_drconf_cell_v2 {
> 
> qemu convention is to use CamelCase for types.

Ok.

> 
> > + uint32_t seq_lmbs;
> > + uint64_t base_addr;
> > + uint32_t drc_index;
> > + uint32_t aa_index;
> > + uint32_t flags;
> > +} __attribute__((packed));
> > +
> > +#define SPAPR_DRCONF_CELL_SIZE 6
> 
> Define this using a sizeof() for safety.

Ok.

> 
> > +/* ibm,dynamic-memory-v2 */
> > +static int spapr_populate_drmem_v2(sPAPRMachineState *spapr, void *fdt,
> > +   int offset, MemoryDeviceInfoList *dimms)
> >  {
> > -MachineState *machine = MACHINE(spapr);
> > -int ret, i, offset;
> > -uint64_t lmb_size = SPAPR_MEMORY_BLOCK_SIZE;
> > -uint32_t prop_lmb_size[] = {0, cpu_to_be32(lmb_size)};
> > -uint32_t hotplug_lmb_start = spapr->hotplug_memory.base / lmb_size;
> > -uint32_t nr_lmbs = (spapr->hotplug_memory.base +
> > -   memory_region_size(>hotplug_memory.mr)) /
> > -   lmb_size;
> >  uint32_t *int_buf, *cur_index, buf_len;
> > -int nr_nodes = nb_numa_nodes ? nb_numa_nodes : 1;
> > -MemoryDeviceInfoList *dimms = NULL;
> > +int ret;
> > +uint64_t lmb_size = SPAPR_MEMORY_BLOCK_SIZE;
> > +uint64_t addr, cur_addr, size;
> > +uint32_t nr_boot_lmbs = (spapr->hotplug_memory.base / lmb_size);
> > +uint64_t mem_end = spapr->hotplug_memory.base +
> > +   memory_region_size(>hotplug_memory.mr);
> > +uint32_t node, nr_entries = 0;
> > +sPAPRDRConnector *drc;
> > +typedef struct drconf_cell_queue {
> > +struct of_drconf_cell_v2 cell;
> > +QSIMPLEQ_ENTRY(drconf_cell_queue) entry;
> > +} drconf_cell_queue;
> 
> Likewise CamelCase here.

Ok.

> 
> > +QSIMPLEQ_HEAD(, drconf_cell_queue) drconf_queue
> > += QSIMPLEQ_HEAD_INITIALIZER(drconf_queue);
> > +drconf_cell_queue *elem, *next;
> > +MemoryDeviceInfoList *info;
> >  
> > -/*
> > - * Don't create the node if there is no hotpluggable memory
> > - */
> > -if (machine->ram_size == machine->maxram_size) {
> > -return 0;

Re: [Qemu-devel] [RFC PATCH v2] spapr: Support ibm, dynamic-memory-v2 property

[David Gibson]

On Mon, Apr 09, 2018 at 11:55:38AM +0530, Bharata B Rao wrote:
> The new property ibm,dynamic-memory-v2 allows memory to be represented
> in a more compact manner in device tree.
> 
> Signed-off-by: Bharata B Rao 
> ---
> v1: https://lists.nongnu.org/archive/html/qemu-devel/2018-03/msg01788.html
> Changes in v1:
> - Minor cleanups in the error paths
> - Rebased on top of ppc-for-2.13
> 
>  docs/specs/ppc-spapr-hotplug.txt |  19 +++
>  hw/ppc/spapr.c   | 257 
> ---
>  include/hw/ppc/spapr.h   |   1 +
>  include/hw/ppc/spapr_ovec.h  |   1 +
>  4 files changed, 233 insertions(+), 45 deletions(-)



> diff --git a/docs/specs/ppc-spapr-hotplug.txt 
> b/docs/specs/ppc-spapr-hotplug.txt
> index f57e2a09c6..cc7833108e 100644
> --- a/docs/specs/ppc-spapr-hotplug.txt
> +++ b/docs/specs/ppc-spapr-hotplug.txt
> @@ -387,4 +387,23 @@ Each LMB list entry consists of the following elements:
>  - A 32bit flags word. The bit at bit position 0x0008 defines whether
>the LMB is assigned to the the partition as of boot time.
>  
> +ibm,dynamic-memory-v2
> +
> +This property describes the dynamically reconfigurable memory. This is
> +an alternate and newer way to describe dyanamically reconfigurable memory.
> +It is a property encoded array that has an integer N (the number of
> +LMB set entries) followed by N LMB set entries. There is an LMB set entry
> +for each sequential group of LMBs that share common attributes.
> +
> +Each LMB set entry consists of the following elements:
> +
> +- Number of sequential LMBs in the entry represented by a 32bit integer.
> +- Logical address of the first LMB in the set encoded as a 64bit integer.
> +- DRC index of the first LMB in the set.
> +- Associativity list index that is used as an index into
> +  ibm,associativity-lookup-arrays property described earlier. This
> +  is used to retrieve the right associativity list to be used for all
> +  the LMBs in this set.
> +- A 32bit flags word that applies to all the LMBs in the set.
> +
>  [1] http://thread.gmane.org/gmane.linux.ports.ppc.embedded/75350/focus=106867
> diff --git a/hw/ppc/spapr.c b/hw/ppc/spapr.c
> index 3ffadd6ac7..4a24fac38c 100644
> --- a/hw/ppc/spapr.c
> +++ b/hw/ppc/spapr.c
> @@ -669,63 +669,139 @@ static uint32_t 
> spapr_pc_dimm_node(MemoryDeviceInfoList *list, ram_addr_t addr)
>  return -1;
>  }
>  
> -/*
> - * Adds ibm,dynamic-reconfiguration-memory node.
> - * Refer to docs/specs/ppc-spapr-hotplug.txt for the documentation
> - * of this device tree node.
> - */
> -static int spapr_populate_drconf_memory(sPAPRMachineState *spapr, void *fdt)
> +struct of_drconf_cell_v2 {

qemu convention is to use CamelCase for types.

> + uint32_t seq_lmbs;
> + uint64_t base_addr;
> + uint32_t drc_index;
> + uint32_t aa_index;
> + uint32_t flags;
> +} __attribute__((packed));
> +
> +#define SPAPR_DRCONF_CELL_SIZE 6

Define this using a sizeof() for safety.

> +/* ibm,dynamic-memory-v2 */
> +static int spapr_populate_drmem_v2(sPAPRMachineState *spapr, void *fdt,
> +   int offset, MemoryDeviceInfoList *dimms)
>  {
> -MachineState *machine = MACHINE(spapr);
> -int ret, i, offset;
> -uint64_t lmb_size = SPAPR_MEMORY_BLOCK_SIZE;
> -uint32_t prop_lmb_size[] = {0, cpu_to_be32(lmb_size)};
> -uint32_t hotplug_lmb_start = spapr->hotplug_memory.base / lmb_size;
> -uint32_t nr_lmbs = (spapr->hotplug_memory.base +
> -   memory_region_size(>hotplug_memory.mr)) /
> -   lmb_size;
>  uint32_t *int_buf, *cur_index, buf_len;
> -int nr_nodes = nb_numa_nodes ? nb_numa_nodes : 1;
> -MemoryDeviceInfoList *dimms = NULL;
> +int ret;
> +uint64_t lmb_size = SPAPR_MEMORY_BLOCK_SIZE;
> +uint64_t addr, cur_addr, size;
> +uint32_t nr_boot_lmbs = (spapr->hotplug_memory.base / lmb_size);
> +uint64_t mem_end = spapr->hotplug_memory.base +
> +   memory_region_size(>hotplug_memory.mr);
> +uint32_t node, nr_entries = 0;
> +sPAPRDRConnector *drc;
> +typedef struct drconf_cell_queue {
> +struct of_drconf_cell_v2 cell;
> +QSIMPLEQ_ENTRY(drconf_cell_queue) entry;
> +} drconf_cell_queue;

Likewise CamelCase here.

> +QSIMPLEQ_HEAD(, drconf_cell_queue) drconf_queue
> += QSIMPLEQ_HEAD_INITIALIZER(drconf_queue);
> +drconf_cell_queue *elem, *next;
> +MemoryDeviceInfoList *info;
>  
> -/*
> - * Don't create the node if there is no hotpluggable memory
> - */
> -if (machine->ram_size == machine->maxram_size) {
> -return 0;
> -}
> +/* Entry to cover RAM and the gap area */
> +elem = g_malloc0(sizeof(drconf_cell_queue));

Please use sizeof(*elem) - it's more robust in case you need to change
types around.

> +elem->cell.seq_lmbs = cpu_to_be32(nr_boot_lmbs);
> +elem->cell.base_addr = cpu_to_be64(0);
> +elem->cell.drc_index 

Re: [Qemu-devel] [RFC PATCH v2] spapr: Support ibm, dynamic-memory-v2 property

[David Gibson]

On Tue, Apr 10, 2018 at 09:45:21AM +0530, Bharata B Rao wrote:
> On Tue, Apr 10, 2018 at 01:02:45PM +1000, David Gibson wrote:
> > On Mon, Apr 09, 2018 at 11:55:38AM +0530, Bharata B Rao wrote:
> > > The new property ibm,dynamic-memory-v2 allows memory to be represented
> > > in a more compact manner in device tree.
> > 
> > I still need to look at this in more detail, but to start with:
> > what's the rationale for this new format?
> > 
> > It's more compact, but why do we care?  The embedded people always
> > whinge about the size of the deivce tree, but I didn't think that was
> > really a concern with PAPR.
> 
> Here's a real example of how this has affected us earlier:
> 
> SLOF's CAS FDT buffer size was initially 32K, was changed to 64k to
> support 1TB guest memory and again changed to 2MB to support 16TB guest
> memory.

Ah.. I hadn't thought of the CAS buffer, that's a legitimate concern.

> With ibm,dynamic-memory-v2 we are less likely to hit such scenarios.
> 
> Also, theoretically it should be more efficient in the guest kernel
> to handle LMB-sets than individual LMBs.
> 
> We aren't there yet, but I believe grouping of LMBs should eventually
> help us do memory hotplug at set (or DIMM) granularity than at individual
> LMB granularity (Again theoretical possibility)

Ok, sounds like it might be useful.

-- 
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


signature.asc
Description: PGP signature

Re: [Qemu-devel] [RFC PATCH v2] spapr: Support ibm, dynamic-memory-v2 property

[David Gibson]

On Wed, Apr 11, 2018 at 01:56:14PM +1000, Alexey Kardashevskiy wrote:
1;5002;0c> On 10/4/18 1:02 pm, David Gibson wrote:
> > On Mon, Apr 09, 2018 at 11:55:38AM +0530, Bharata B Rao wrote:
> >> The new property ibm,dynamic-memory-v2 allows memory to be represented
> >> in a more compact manner in device tree.
> > 
> > I still need to look at this in more detail, but to start with:
> > what's the rationale for this new format?
> > 
> > It's more compact, but why do we care?  The embedded people always
> > whinge about the size of the deivce tree, but I didn't think that was
> > really a concern with PAPR.
> 
> 
> Well, booting a guest with 500 pci devices (let's say emulated e1000 or
> virtio-net) creates >20sec delay in the guest while it is fetching the
> device tree in early setup, property by property, I even have a patch for
> pseries guest to get FDT as a whole blob from SLOF. It is not The Problem
> but still annoying.

Right, but 500 PCI devices is not this case.  Sounds like the slowness
there is mostly from having lots of nodes and properties and therefore
lots of individual OF calls.  The old dynamic memory format is still
just one big property, so it shouldn't have nearly the same impact.

Besides, Bharata pretty much convinced me already with his other reasons.

-- 
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


signature.asc
Description: PGP signature

Re: [Qemu-devel] [RFC PATCH v2] spapr: Support ibm, dynamic-memory-v2 property

[Alexey Kardashevskiy]

On 10/4/18 1:02 pm, David Gibson wrote:
> On Mon, Apr 09, 2018 at 11:55:38AM +0530, Bharata B Rao wrote:
>> The new property ibm,dynamic-memory-v2 allows memory to be represented
>> in a more compact manner in device tree.
> 
> I still need to look at this in more detail, but to start with:
> what's the rationale for this new format?
> 
> It's more compact, but why do we care?  The embedded people always
> whinge about the size of the deivce tree, but I didn't think that was
> really a concern with PAPR.


Well, booting a guest with 500 pci devices (let's say emulated e1000 or
virtio-net) creates >20sec delay in the guest while it is fetching the
device tree in early setup, property by property, I even have a patch for
pseries guest to get FDT as a whole blob from SLOF. It is not The Problem
but still annoying.


-- 
Alexey

Re: [Qemu-devel] [RFC PATCH v2] spapr: Support ibm, dynamic-memory-v2 property

[Bharata B Rao]

On Tue, Apr 10, 2018 at 01:02:45PM +1000, David Gibson wrote:
> On Mon, Apr 09, 2018 at 11:55:38AM +0530, Bharata B Rao wrote:
> > The new property ibm,dynamic-memory-v2 allows memory to be represented
> > in a more compact manner in device tree.
> 
> I still need to look at this in more detail, but to start with:
> what's the rationale for this new format?
> 
> It's more compact, but why do we care?  The embedded people always
> whinge about the size of the deivce tree, but I didn't think that was
> really a concern with PAPR.

Here's a real example of how this has affected us earlier:

SLOF's CAS FDT buffer size was initially 32K, was changed to 64k to
support 1TB guest memory and again changed to 2MB to support 16TB guest
memory.

With ibm,dynamic-memory-v2 we are less likely to hit such scenarios.

Also, theoretically it should be more efficient in the guest kernel
to handle LMB-sets than individual LMBs.

We aren't there yet, but I believe grouping of LMBs should eventually
help us do memory hotplug at set (or DIMM) granularity than at individual
LMB granularity (Again theoretical possibility)

Regards,
Bharata.

Re: [Qemu-devel] [RFC PATCH v2] spapr: Support ibm, dynamic-memory-v2 property

[David Gibson]

On Mon, Apr 09, 2018 at 11:55:38AM +0530, Bharata B Rao wrote:
> The new property ibm,dynamic-memory-v2 allows memory to be represented
> in a more compact manner in device tree.

I still need to look at this in more detail, but to start with:
what's the rationale for this new format?

It's more compact, but why do we care?  The embedded people always
whinge about the size of the deivce tree, but I didn't think that was
really a concern with PAPR.

> 
> Signed-off-by: Bharata B Rao 
> ---
> v1: https://lists.nongnu.org/archive/html/qemu-devel/2018-03/msg01788.html
> Changes in v1:
> - Minor cleanups in the error paths
> - Rebased on top of ppc-for-2.13
> 
>  docs/specs/ppc-spapr-hotplug.txt |  19 +++
>  hw/ppc/spapr.c   | 257 
> ---
>  include/hw/ppc/spapr.h   |   1 +
>  include/hw/ppc/spapr_ovec.h  |   1 +
>  4 files changed, 233 insertions(+), 45 deletions(-)
> 
> diff --git a/docs/specs/ppc-spapr-hotplug.txt 
> b/docs/specs/ppc-spapr-hotplug.txt
> index f57e2a09c6..cc7833108e 100644
> --- a/docs/specs/ppc-spapr-hotplug.txt
> +++ b/docs/specs/ppc-spapr-hotplug.txt
> @@ -387,4 +387,23 @@ Each LMB list entry consists of the following elements:
>  - A 32bit flags word. The bit at bit position 0x0008 defines whether
>the LMB is assigned to the the partition as of boot time.
>  
> +ibm,dynamic-memory-v2
> +
> +This property describes the dynamically reconfigurable memory. This is
> +an alternate and newer way to describe dyanamically reconfigurable memory.
> +It is a property encoded array that has an integer N (the number of
> +LMB set entries) followed by N LMB set entries. There is an LMB set entry
> +for each sequential group of LMBs that share common attributes.
> +
> +Each LMB set entry consists of the following elements:
> +
> +- Number of sequential LMBs in the entry represented by a 32bit integer.
> +- Logical address of the first LMB in the set encoded as a 64bit integer.
> +- DRC index of the first LMB in the set.
> +- Associativity list index that is used as an index into
> +  ibm,associativity-lookup-arrays property described earlier. This
> +  is used to retrieve the right associativity list to be used for all
> +  the LMBs in this set.
> +- A 32bit flags word that applies to all the LMBs in the set.
> +
>  [1] http://thread.gmane.org/gmane.linux.ports.ppc.embedded/75350/focus=106867
> diff --git a/hw/ppc/spapr.c b/hw/ppc/spapr.c
> index 3ffadd6ac7..4a24fac38c 100644
> --- a/hw/ppc/spapr.c
> +++ b/hw/ppc/spapr.c
> @@ -669,63 +669,139 @@ static uint32_t 
> spapr_pc_dimm_node(MemoryDeviceInfoList *list, ram_addr_t addr)
>  return -1;
>  }
>  
> -/*
> - * Adds ibm,dynamic-reconfiguration-memory node.
> - * Refer to docs/specs/ppc-spapr-hotplug.txt for the documentation
> - * of this device tree node.
> - */
> -static int spapr_populate_drconf_memory(sPAPRMachineState *spapr, void *fdt)
> +struct of_drconf_cell_v2 {
> + uint32_t seq_lmbs;
> + uint64_t base_addr;
> + uint32_t drc_index;
> + uint32_t aa_index;
> + uint32_t flags;
> +} __attribute__((packed));
> +
> +#define SPAPR_DRCONF_CELL_SIZE 6
> +
> +/* ibm,dynamic-memory-v2 */
> +static int spapr_populate_drmem_v2(sPAPRMachineState *spapr, void *fdt,
> +   int offset, MemoryDeviceInfoList *dimms)
>  {
> -MachineState *machine = MACHINE(spapr);
> -int ret, i, offset;
> -uint64_t lmb_size = SPAPR_MEMORY_BLOCK_SIZE;
> -uint32_t prop_lmb_size[] = {0, cpu_to_be32(lmb_size)};
> -uint32_t hotplug_lmb_start = spapr->hotplug_memory.base / lmb_size;
> -uint32_t nr_lmbs = (spapr->hotplug_memory.base +
> -   memory_region_size(>hotplug_memory.mr)) /
> -   lmb_size;
>  uint32_t *int_buf, *cur_index, buf_len;
> -int nr_nodes = nb_numa_nodes ? nb_numa_nodes : 1;
> -MemoryDeviceInfoList *dimms = NULL;
> +int ret;
> +uint64_t lmb_size = SPAPR_MEMORY_BLOCK_SIZE;
> +uint64_t addr, cur_addr, size;
> +uint32_t nr_boot_lmbs = (spapr->hotplug_memory.base / lmb_size);
> +uint64_t mem_end = spapr->hotplug_memory.base +
> +   memory_region_size(>hotplug_memory.mr);
> +uint32_t node, nr_entries = 0;
> +sPAPRDRConnector *drc;
> +typedef struct drconf_cell_queue {
> +struct of_drconf_cell_v2 cell;
> +QSIMPLEQ_ENTRY(drconf_cell_queue) entry;
> +} drconf_cell_queue;
> +QSIMPLEQ_HEAD(, drconf_cell_queue) drconf_queue
> += QSIMPLEQ_HEAD_INITIALIZER(drconf_queue);
> +drconf_cell_queue *elem, *next;
> +MemoryDeviceInfoList *info;
>  
> -/*
> - * Don't create the node if there is no hotpluggable memory
> - */
> -if (machine->ram_size == machine->maxram_size) {
> -return 0;
> -}
> +/* Entry to cover RAM and the gap area */
> +elem = g_malloc0(sizeof(drconf_cell_queue));
> +elem->cell.seq_lmbs = cpu_to_be32(nr_boot_lmbs);
> 

[Qemu-devel] [RFC PATCH v2] spapr: Support ibm, dynamic-memory-v2 property

[Bharata B Rao]

The new property ibm,dynamic-memory-v2 allows memory to be represented
in a more compact manner in device tree.

Signed-off-by: Bharata B Rao 
---
v1: https://lists.nongnu.org/archive/html/qemu-devel/2018-03/msg01788.html
Changes in v1:
- Minor cleanups in the error paths
- Rebased on top of ppc-for-2.13

 docs/specs/ppc-spapr-hotplug.txt |  19 +++
 hw/ppc/spapr.c   | 257 ---
 include/hw/ppc/spapr.h   |   1 +
 include/hw/ppc/spapr_ovec.h  |   1 +
 4 files changed, 233 insertions(+), 45 deletions(-)

diff --git a/docs/specs/ppc-spapr-hotplug.txt b/docs/specs/ppc-spapr-hotplug.txt
index f57e2a09c6..cc7833108e 100644
--- a/docs/specs/ppc-spapr-hotplug.txt
+++ b/docs/specs/ppc-spapr-hotplug.txt
@@ -387,4 +387,23 @@ Each LMB list entry consists of the following elements:
 - A 32bit flags word. The bit at bit position 0x0008 defines whether
   the LMB is assigned to the the partition as of boot time.
 
+ibm,dynamic-memory-v2
+
+This property describes the dynamically reconfigurable memory. This is
+an alternate and newer way to describe dyanamically reconfigurable memory.
+It is a property encoded array that has an integer N (the number of
+LMB set entries) followed by N LMB set entries. There is an LMB set entry
+for each sequential group of LMBs that share common attributes.
+
+Each LMB set entry consists of the following elements:
+
+- Number of sequential LMBs in the entry represented by a 32bit integer.
+- Logical address of the first LMB in the set encoded as a 64bit integer.
+- DRC index of the first LMB in the set.
+- Associativity list index that is used as an index into
+  ibm,associativity-lookup-arrays property described earlier. This
+  is used to retrieve the right associativity list to be used for all
+  the LMBs in this set.
+- A 32bit flags word that applies to all the LMBs in the set.
+
 [1] http://thread.gmane.org/gmane.linux.ports.ppc.embedded/75350/focus=106867
diff --git a/hw/ppc/spapr.c b/hw/ppc/spapr.c
index 3ffadd6ac7..4a24fac38c 100644
--- a/hw/ppc/spapr.c
+++ b/hw/ppc/spapr.c
@@ -669,63 +669,139 @@ static uint32_t spapr_pc_dimm_node(MemoryDeviceInfoList 
*list, ram_addr_t addr)
 return -1;
 }
 
-/*
- * Adds ibm,dynamic-reconfiguration-memory node.
- * Refer to docs/specs/ppc-spapr-hotplug.txt for the documentation
- * of this device tree node.
- */
-static int spapr_populate_drconf_memory(sPAPRMachineState *spapr, void *fdt)
+struct of_drconf_cell_v2 {
+ uint32_t seq_lmbs;
+ uint64_t base_addr;
+ uint32_t drc_index;
+ uint32_t aa_index;
+ uint32_t flags;
+} __attribute__((packed));
+
+#define SPAPR_DRCONF_CELL_SIZE 6
+
+/* ibm,dynamic-memory-v2 */
+static int spapr_populate_drmem_v2(sPAPRMachineState *spapr, void *fdt,
+   int offset, MemoryDeviceInfoList *dimms)
 {
-MachineState *machine = MACHINE(spapr);
-int ret, i, offset;
-uint64_t lmb_size = SPAPR_MEMORY_BLOCK_SIZE;
-uint32_t prop_lmb_size[] = {0, cpu_to_be32(lmb_size)};
-uint32_t hotplug_lmb_start = spapr->hotplug_memory.base / lmb_size;
-uint32_t nr_lmbs = (spapr->hotplug_memory.base +
-   memory_region_size(>hotplug_memory.mr)) /
-   lmb_size;
 uint32_t *int_buf, *cur_index, buf_len;
-int nr_nodes = nb_numa_nodes ? nb_numa_nodes : 1;
-MemoryDeviceInfoList *dimms = NULL;
+int ret;
+uint64_t lmb_size = SPAPR_MEMORY_BLOCK_SIZE;
+uint64_t addr, cur_addr, size;
+uint32_t nr_boot_lmbs = (spapr->hotplug_memory.base / lmb_size);
+uint64_t mem_end = spapr->hotplug_memory.base +
+   memory_region_size(>hotplug_memory.mr);
+uint32_t node, nr_entries = 0;
+sPAPRDRConnector *drc;
+typedef struct drconf_cell_queue {
+struct of_drconf_cell_v2 cell;
+QSIMPLEQ_ENTRY(drconf_cell_queue) entry;
+} drconf_cell_queue;
+QSIMPLEQ_HEAD(, drconf_cell_queue) drconf_queue
+= QSIMPLEQ_HEAD_INITIALIZER(drconf_queue);
+drconf_cell_queue *elem, *next;
+MemoryDeviceInfoList *info;
 
-/*
- * Don't create the node if there is no hotpluggable memory
- */
-if (machine->ram_size == machine->maxram_size) {
-return 0;
-}
+/* Entry to cover RAM and the gap area */
+elem = g_malloc0(sizeof(drconf_cell_queue));
+elem->cell.seq_lmbs = cpu_to_be32(nr_boot_lmbs);
+elem->cell.base_addr = cpu_to_be64(0);
+elem->cell.drc_index = cpu_to_be32(0);
+elem->cell.aa_index = cpu_to_be32(-1);
+elem->cell.flags = cpu_to_be32(SPAPR_LMB_FLAGS_RESERVED |
+   SPAPR_LMB_FLAGS_DRC_INVALID);
+QSIMPLEQ_INSERT_TAIL(_queue, elem, entry);
+nr_entries++;
+
+cur_addr = spapr->hotplug_memory.base;
+for (info = dimms; info; info = info->next) {
+PCDIMMDeviceInfo *di = info->value->u.dimm.data;
+
+addr = di->addr;
+size = di->size;
+node = di->node;
+