spapr: Don't create ibm, dynamic-reconfiguration-memory w/o DR LMBs

If guest doesn't have any dynamically reconfigurable (DR) logical memory
blocks (LMB), then we shouldn't create ibm,dynamic-reconfiguration-memory
device tree node.

Signed-off-by: Bharata B Rao <bharata@linux.vnet.ibm.com>
---
This applies against ppc-for-2.6 branch of David Gibson's tree.

 hw/ppc/spapr.c | 9 ++++++++-
 1 file changed, 8 insertions(+), 1 deletion(-)

On Tue, Jan 19, 2016 at 10:09:21AM +0530, Bharata B Rao wrote:
> If guest doesn't have any dynamically reconfigurable (DR) logical memory
> blocks (LMB), then we shouldn't create ibm,dynamic-reconfiguration-memory
> device tree node.
> 
> Signed-off-by: Bharata B Rao <bharata@linux.vnet.ibm.com>
> ---
> This applies against ppc-for-2.6 branch of David Gibson's tree.

Applied to ppc-for-2.6, thanks.

> 
>  hw/ppc/spapr.c | 9 ++++++++-
>  1 file changed, 8 insertions(+), 1 deletion(-)
> 
> diff --git a/hw/ppc/spapr.c b/hw/ppc/spapr.c
> index 50e5a26..86e5023 100644
> --- a/hw/ppc/spapr.c
> +++ b/hw/ppc/spapr.c
> @@ -763,6 +763,13 @@ static int spapr_populate_drconf_memory(sPAPRMachineState *spapr, void *fdt)
>      int nr_nodes = nb_numa_nodes ? nb_numa_nodes : 1;
>  
>      /*
> +     * Don't create the node if there are no DR LMBs.
> +     */
> +    if (!nr_lmbs) {
> +        return 0;
> +    }
> +
> +    /*
>       * Allocate enough buffer size to fit in ibm,dynamic-memory
>       * or ibm,associativity-lookup-arrays
>       */
> @@ -868,7 +875,7 @@ int spapr_h_cas_compose_response(sPAPRMachineState *spapr,
>          _FDT((spapr_fixup_cpu_dt(fdt, spapr)));
>      }
>  
> -    /* Generate memory nodes or ibm,dynamic-reconfiguration-memory node */
> +    /* Generate ibm,dynamic-reconfiguration-memory node if required */
>      if (memory_update && smc->dr_lmb_enabled) {
>          _FDT((spapr_populate_drconf_memory(spapr, fdt)));
>      }

On Tue, Jan 19, 2016 at 04:00:25PM +1100, David Gibson wrote:
> On Tue, Jan 19, 2016 at 10:09:21AM +0530, Bharata B Rao wrote:
> > If guest doesn't have any dynamically reconfigurable (DR) logical memory
> > blocks (LMB), then we shouldn't create ibm,dynamic-reconfiguration-memory
> > device tree node.
> > 
> > Signed-off-by: Bharata B Rao <bharata@linux.vnet.ibm.com>
> > ---
> > This applies against ppc-for-2.6 branch of David Gibson's tree.
> 
> Applied to ppc-for-2.6, thanks.

There is a slight change in memory nodes representation in DT after this fix
that could result in the following behaviour before and after migration.

For a guest with -m 4G -numa node,nodeid=0,mem=2G -numa node,nodeid=1,mem=2G,
the DT under /proc/device-tree changes like this:

Guest started with QEMU w/o this fix
------------------------------------
memory@0
memory@80000000
ibm,dynamic-reconfiguration-memory

Guest migrated to QEMU w/ this fix included
-------------------------------------------
memory@0
memory@80000000
ibm,dynamic-reconfiguration-memory

After next reboot
-----------------
memory@0
memory@80000000

I guess this is ok, but wanted to sound out this change explicitly.

Regards,
Bharata.

On Wed, Jan 20, 2016 at 11:00:39AM +0530, Bharata B Rao wrote:
> On Tue, Jan 19, 2016 at 04:00:25PM +1100, David Gibson wrote:
> > On Tue, Jan 19, 2016 at 10:09:21AM +0530, Bharata B Rao wrote:
> > > If guest doesn't have any dynamically reconfigurable (DR) logical memory
> > > blocks (LMB), then we shouldn't create ibm,dynamic-reconfiguration-memory
> > > device tree node.
> > > 
> > > Signed-off-by: Bharata B Rao <bharata@linux.vnet.ibm.com>
> > > ---
> > > This applies against ppc-for-2.6 branch of David Gibson's tree.
> > 
> > Applied to ppc-for-2.6, thanks.
> 
> There is a slight change in memory nodes representation in DT after this fix
> that could result in the following behaviour before and after migration.
> 
> For a guest with -m 4G -numa node,nodeid=0,mem=2G -numa node,nodeid=1,mem=2G,
> the DT under /proc/device-tree changes like this:
> 
> Guest started with QEMU w/o this fix
> ------------------------------------
> memory@0
> memory@80000000
> ibm,dynamic-reconfiguration-memory
> 
> Guest migrated to QEMU w/ this fix included
> -------------------------------------------
> memory@0
> memory@80000000
> ibm,dynamic-reconfiguration-memory
> 
> After next reboot
> -----------------
> memory@0
> memory@80000000
> 
> I guess this is ok, but wanted to sound out this change explicitly.

Yeah, I think that should be ok.

Generally device tree changes won't break migration, because the guest
(or SLOF) will have already grabbed the old device tree from the
source qemu.