target-ppc: Enhance CPU nodes of SPAPR-generated device tree

PATCH In review Prerna Saxena 5 participants 11 messages Aug 8, 2013 – Aug 14, 2013

Share & tools

Prerna Saxena

author

2013-08-08 07:26 UTC #0 lore raw

v3 cover target-ppc: Enhance CPU nodes of SPAPR-generated device tree

By default on KVM or when user asks for it via -cpu host, cpu_model will be "host" and sPAPR merely upper-cases it for the SLOF device tree.

PATCH 1/2 : Change the SPAPR code so that we get the underlying CPU type,

             e.g., "POWER7_V2.3@0" in the device tree.

PATCH 2/2 : Make the device-tree CPU nodes PAPR-compliant.

Changelog from v2:
PATCH 1/2 : Reworked and augmented by Andres Farber against original posted by
Prerna.
PATCH 2/2 : New.

Regards,

Signature · 5 lines

Prerna Saxena

Linux Technology Centre,
IBM Systems and Technology Lab,
Bangalore, India

Prerna Saxena

author

2013-08-08 07:30 UTC #1 lore raw

PATCH v3 1/2 target-ppc: Get CPU name to correct reflect its model in the SLOF device tree.

From: Andreas Farber <[email protected]>
Date: Wed, 7 Aug 2013 14:50:41 +0530
Subject: [PATCH 1/2] By default on KVM or when user asks for it via -cpu
host, cpu_model will be "host" and sPAPR merely
upper-cases it for the SLOF device tree.

Change it so that we get the underlying CPU type, e.g., "POWER7_V2.3@0".

Tested-by Prerna Saxena <[email protected]>

Signed-off-by Andreas Färber <[email protected]>

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

hw/ppc/spapr.c +11 -1

index 16bfab9..59e2fea 100644
@@ -1072,7 +1072,7 @@ static void ppc_spapr_init(QEMUMachineInitArgs *args)
     const char *kernel_cmdline = args->kernel_cmdline;
     const char *initrd_filename = args->initrd_filename;
     const char *boot_device = args->boot_device;
-    PowerPCCPU *cpu;
+    PowerPCCPU *cpu = NULL;
     CPUPPCState *env;
     PCIHostState *phb;
     int i;

@@ -1307,6 +1307,16 @@ static void ppc_spapr_init(QEMUMachineInitArgs *args)
     register_savevm_live(NULL, "spapr/htab", -1, 1,
                          &savevm_htab_handlers, spapr);
 
+    if (kvm_enabled() && strcmp(cpu_model, "host") == 0) {
+        ObjectClass *cpu_class = object_get_class(OBJECT(cpu));
+        ObjectClass *parent_cpu_class = object_class_get_parent(cpu_class);
+
+        const char *parent_name = object_class_get_name(parent_cpu_class);
+
+        cpu_model = g_strndup(parent_name,
+            strlen(parent_name) - strlen("-" TYPE_POWERPC_CPU));
+    }
+
     /* Prepare the device tree */
     spapr->fdt_skel = spapr_create_fdt_skel(cpu_model,
                                             initrd_base, initrd_size,

Signature · 9 lines

1.7.11.4


-- 
Prerna Saxena

Linux Technology Centre,
IBM Systems and Technology Lab,
Bangalore, India

Prerna Saxena

author

2013-08-08 07:32 UTC #2 lore raw

PATCH v3 2/2 target-ppc: Enhance CPU nodes of device tree to be PAPR compliant.

In reply to Prerna Saxena

From: Prerna Saxena <[email protected]>
Date: Thu, 8 Aug 2013 06:38:03 +0530
Subject: [PATCH 2/2] Enhance CPU nodes of device tree to be PAPR compliant.

This is based on patch from Andreas which enables the default CPU with KVM to show up as "-cpu <type>", such as "POWER7_V2.3@0"

While this is definitely, more descriptive, PAPR mandates the device tree CPU node names to be of the form : "PowerPC,<name>" where <name> should not have underscores.
Hence replacing the CPU model (which has underscores) with CPU alias.

With this patch, the CPU nodes of device tree show up as :
/proc/device-tree/cpus/PowerPC,POWER7@0/... /proc/device-tree/cpus/PowerPC,POWER7@4/...

Signed-off-by Prerna Saxena <[email protected]>

---
 hw/ppc/spapr.c | 22 ++++++++++++++++++++--
 1 file changed, 20 insertions(+), 2 deletions(-)

hw/ppc/spapr.c +20 -2

index 59e2fea..8efd84e 100644
@@ -43,6 +43,7 @@
 #include "hw/pci-host/spapr.h"
 #include "hw/ppc/xics.h"
 #include "hw/pci/msi.h"
+#include "cpu-models.h"
 
 #include "hw/pci/pci.h"

@@ -80,6 +81,8 @@
 
 #define HTAB_SIZE(spapr)        (1ULL << ((spapr)->htab_shift))
 
+#define PPC_DEVTREE_STR         "PowerPC,"
+
 sPAPREnvironment *spapr;
 
 int spapr_allocate_irq(int hint, bool lsi)

@@ -322,9 +325,16 @@ static void *spapr_create_fdt_skel(const char *cpu_model,
     _FDT((fdt_property_cell(fdt, "#address-cells", 0x1)));
     _FDT((fdt_property_cell(fdt, "#size-cells", 0x0)));
 
-    modelname = g_strdup(cpu_model);
+    /*
+     * PAPR convention mandates that
+     * Device tree nodes must be named as:
+     * PowerPC,CPU-NAME@...
+     * Also, CPU-NAME must not have underscores.(hence use of CPU-ALIAS)
+     */
+
+    modelname = g_strdup_printf(PPC_DEVTREE_STR "%s", cpu_model);
 
-    for (i = 0; i < strlen(modelname); i++) {
+    for (i = strlen(PPC_DEVTREE_STR); i < strlen(modelname); i++) {
         modelname[i] = toupper(modelname[i]);
     }

@@ -1315,6 +1325,14 @@ static void ppc_spapr_init(QEMUMachineInitArgs *args)
 
         cpu_model = g_strndup(parent_name,
             strlen(parent_name) - strlen("-" TYPE_POWERPC_CPU));
+
+        for (i = 0; ppc_cpu_aliases[i].model != NULL; i++) {
+            if (strcmp(ppc_cpu_aliases[i].model, cpu_model) == 0) {
+                g_free(cpu_model);
+                cpu_model = g_strndup(ppc_cpu_aliases[i].alias,
+                                strlen(ppc_cpu_aliases[i].alias));
+            }
+        }
     }
 
     /* Prepare the device tree */

Signature · 10 lines

1.7.11.4



-- 
Prerna Saxena

Linux Technology Centre,
IBM Systems and Technology Lab,
Bangalore, India

Andreas Färber

2013-08-08 10:34 UTC #3 lore raw

Re: [Qemu-devel] [PATCH 2/2] [v3] target-ppc: Enhance CPU nodes of device tree to be PAPR compliant.

Am 08.08.2013 09:26, schrieb Prerna Saxena:

Quoted 13 lines

From: Prerna Saxena <[email protected]>
Date: Thu, 8 Aug 2013 06:38:03 +0530
Subject: [PATCH 2/2] Enhance CPU nodes of device tree to be PAPR compliant.
This is based on patch from Andreas which enables the default CPU with KVM to show up as "-cpu <type>", such as "POWER7_V2.3@0"
While this is definitely, more descriptive, PAPR mandates the device tree CPU node names to be of the form : "PowerPC,<name>" where <name> should not have underscores.
Hence replacing the CPU model (which has underscores) with CPU alias.

Quoted 5 lines

With this patch, the CPU nodes of device tree show up as :
/proc/device-tree/cpus/PowerPC,POWER7@0/... /proc/device-tree/cpus/PowerPC,POWER7@4/...
Signed-off-by Prerna Saxena <[email protected]>

Not yet happy...

Quoted 34 lines

---
 hw/ppc/spapr.c | 22 ++++++++++++++++++++--
 1 file changed, 20 insertions(+), 2 deletions(-)

hw/ppc/spapr.c +7 -1

index 59e2fea..8efd84e 100644
@@ -43,6 +43,7 @@
 #include "hw/pci-host/spapr.h"
 #include "hw/ppc/xics.h"
 #include "hw/pci/msi.h"
+#include "cpu-models.h"
 
 #include "hw/pci/pci.h"

@@ -80,6 +81,8 @@
 
 #define HTAB_SIZE(spapr)        (1ULL << ((spapr)->htab_shift))
 
+#define PPC_DEVTREE_STR         "PowerPC,"
+
 sPAPREnvironment *spapr;
 
 int spapr_allocate_irq(int hint, bool lsi)

@@ -322,9 +325,16 @@ static void *spapr_create_fdt_skel(const char *cpu_model,
     _FDT((fdt_property_cell(fdt, "#address-cells", 0x1)));
     _FDT((fdt_property_cell(fdt, "#size-cells", 0x0)));
 
-    modelname = g_strdup(cpu_model);
+    /*
+     * PAPR convention mandates that
+     * Device tree nodes must be named as:
+     * PowerPC,CPU-NAME@...

hw/ppc/spapr.c static void *spapr_create_fdt_skel(const char *cpu_model, · line 340

Quoted 10 lines

hw/ppc/spapr.c +5 -1

+     * Also, CPU-NAME must not have underscores.(hence use of CPU-ALIAS)
+     */
+
+    modelname = g_strdup_printf(PPC_DEVTREE_STR "%s", cpu_model);
 
-    for (i = 0; i < strlen(modelname); i++) {
+    for (i = strlen(PPC_DEVTREE_STR); i < strlen(modelname); i++) {
         modelname[i] = toupper(modelname[i]);
     }

One of your colleagues had brought up that "PowerPC," prefix were not mandatory - is it *required* by the PAPR spec now, or is it just that the IBM CPUs used with PAPR happen to have such a name?

Quoted 5 lines

hw/ppc/spapr.c +1 -0

@@ -1315,6 +1325,14 @@ static void ppc_spapr_init(QEMUMachineInitArgs *args)
 
         cpu_model = g_strndup(parent_name,
             strlen(parent_name) - strlen("-" TYPE_POWERPC_CPU));
+

hw/ppc/spapr.c static void ppc_spapr_init(QEMUMachineInitArgs *args) · line 1338

Quoted 10 lines

hw/ppc/spapr.c +7 -0

+        for (i = 0; ppc_cpu_aliases[i].model != NULL; i++) {
+            if (strcmp(ppc_cpu_aliases[i].model, cpu_model) == 0) {
+                g_free(cpu_model);
+                cpu_model = g_strndup(ppc_cpu_aliases[i].alias,
+                                strlen(ppc_cpu_aliases[i].alias));
+            }
+        }
     }
 
     /* Prepare the device tree */

This is still fixing up the name in the wrong place: -cpu POWER7_v2.3 will not get fixed, only -cpu host or KVM's default.

The solution I had discussed with Alex is the following: When devices need to expose their name to firmware in a special way, we have the DeviceClass::fw_name field. All we have to do is assign it and use it instead of cpu_model if non-NULL, just like we assign DeviceClass::desc. The way to do it would be to extend the family of POWERPC_DEF* macros to specify the additional field on the relevant CPU models.

Therefore my above question: Would it be sufficient to explicitly name POWER7_v2.3 PowerPC,POWER7 etc. and to drop the upper-casing? Or would we also need to name a CPU such as MPC8572E (random Freescale CPU where I don't know the expected fw_name and that is unlikely to occur/work in sPAPR) "PowerPC,MPC8572E" if someone specified it with -cpu MPC8572E?

Regards,
Andreas

Signature · 2 lines

SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg

Prerna Saxena

author

2013-08-12 04:44 UTC #4 lore raw

Re: [Qemu-devel] [PATCH 2/2] [v3] target-ppc: Enhance CPU nodes of device tree to be PAPR compliant.

Quoted 14 lines · Andreas Färber

Am 08.08.2013 09:26, schrieb Prerna Saxena:
Quoted 13 lines
From: Prerna Saxena <[email protected]>
Date: Thu, 8 Aug 2013 06:38:03 +0530
Subject: [PATCH 2/2] Enhance CPU nodes of device tree to be PAPR compliant.
This is based on patch from Andreas which enables the default CPU with KVM to show up as "-cpu <type>", such as "POWER7_V2.3@0"
While this is definitely, more descriptive, PAPR mandates the device tree CPU node names to be of the form : "PowerPC,<name>" where <name> should not have underscores.
Hence replacing the CPU model (which has underscores) with CPU alias.

Quoted 7 lines

Quoted 5 lines
With this patch, the CPU nodes of device tree show up as :
/proc/device-tree/cpus/PowerPC,POWER7@0/... /proc/device-tree/cpus/PowerPC,POWER7@4/...
Signed-off-by Prerna Saxena <[email protected]>
Not yet happy...

Quoted 40 lines

---
 hw/ppc/spapr.c | 22 ++++++++++++++++++++--
 1 file changed, 20 insertions(+), 2 deletions(-)

hw/ppc/spapr.c +11 -1

index 59e2fea..8efd84e 100644
@@ -43,6 +43,7 @@
 #include "hw/pci-host/spapr.h"
 #include "hw/ppc/xics.h"
 #include "hw/pci/msi.h"
+#include "cpu-models.h"
 
 #include "hw/pci/pci.h"

@@ -80,6 +81,8 @@
 
 #define HTAB_SIZE(spapr)        (1ULL << ((spapr)->htab_shift))
 
+#define PPC_DEVTREE_STR         "PowerPC,"
+
 sPAPREnvironment *spapr;
 
 int spapr_allocate_irq(int hint, bool lsi)

@@ -322,9 +325,16 @@ static void *spapr_create_fdt_skel(const char *cpu_model,
     _FDT((fdt_property_cell(fdt, "#address-cells", 0x1)));
     _FDT((fdt_property_cell(fdt, "#size-cells", 0x0)));
 
-    modelname = g_strdup(cpu_model);
+    /*
+     * PAPR convention mandates that
+     * Device tree nodes must be named as:
+     * PowerPC,CPU-NAME@...
+     * Also, CPU-NAME must not have underscores.(hence use of CPU-ALIAS)
+     */
+
+    modelname = g_strdup_printf(PPC_DEVTREE_STR "%s", cpu_model);

Quoted 9 lines

hw/ppc/spapr.c static void *spapr_create_fdt_skel(const char *cpu_model, · line 340
Quoted 5 lines
hw/ppc/spapr.c +1 -1
-    for (i = 0; i < strlen(modelname); i++) {
+    for (i = strlen(PPC_DEVTREE_STR); i < strlen(modelname); i++) {
         modelname[i] = toupper(modelname[i]);
     }
 
One of your colleagues had brought up that "PowerPC," prefix were not mandatory - is it *required* by the PAPR spec now, or is it just that the IBM CPUs used with PAPR happen to have such a name?

I dont know what context lead to this observation. However, PAPR mentions the following nomenclature guideline:

"The value of this property shall be of the form: “PowerPC,<name>”, where <name> is the name of the processor chip which may be displayed to the user. <name> shall not contain underscores."

I think this name guideline will hold good for all PAPR compliant processors.

Quoted 20 lines

Quoted 6 lines

hw/ppc/spapr.c +1 -0

@@ -1315,6 +1325,14 @@ static void ppc_spapr_init(QEMUMachineInitArgs *args)
 
         cpu_model = g_strndup(parent_name,
             strlen(parent_name) - strlen("-" TYPE_POWERPC_CPU));
+

hw/ppc/spapr.c static void ppc_spapr_init(QEMUMachineInitArgs *args) · line 1338

Quoted 10 lines

hw/ppc/spapr.c +7 -0

+        for (i = 0; ppc_cpu_aliases[i].model != NULL; i++) {
+            if (strcmp(ppc_cpu_aliases[i].model, cpu_model) == 0) {
+                g_free(cpu_model);
+                cpu_model = g_strndup(ppc_cpu_aliases[i].alias,
+                                strlen(ppc_cpu_aliases[i].alias));
+            }
+        }
     }
 
     /* Prepare the device tree */

This is still fixing up the name in the wrong place: -cpu POWER7_v2.3 will not get fixed, only -cpu host or KVM's default.

Quoted 7 lines

The solution I had discussed with Alex is the following: When devices need to expose their name to firmware in a special way, we have the DeviceClass::fw_name field. All we have to do is assign it and use it instead of cpu_model if non-NULL, just like we assign DeviceClass::desc. The way to do it would be to extend the family of POWERPC_DEF* macros to specify the additional field on the relevant CPU models.

Would this be the same use-case as reflected by: ppc_cpu_aliases.alias ? If so, do we really need a separate field to convey the same information ?

Quoted 7 lines

Therefore my above question: Would it be sufficient to explicitly name POWER7_v2.3 PowerPC,POWER7 etc. and to drop the upper-casing? Or would we also need to name a CPU such as MPC8572E (random Freescale CPU where I don't know the expected fw_name and that is unlikely to occur/work in sPAPR) "PowerPC,MPC8572E" if someone specified it with -cpu MPC8572E?

If this is not a PAPR-compliant CPU, I dont think the PAPR naming convention is of any good.
I havent worked with non-PAPR cpus. Is the device tree for such CPUs generated by routines in hw/ppc/spapr.c ? Or do they have custom routines to generate appropriate device tree nodes ?

Regards,

Signature · 5 lines

Prerna Saxena

Linux Technology Centre,
IBM Systems and Technology Lab,
Bangalore, India

Benjamin Herrenschmidt

2013-08-12 06:03 UTC #5 lore raw

Re: [Qemu-devel] [Qemu-ppc] [PATCH 2/2] [v3] target-ppc: Enhance CPU nodes of device tree to be PAPR compliant.

On Mon, 2013-08-12 at 10:07 +0530, Prerna Saxena wrote:

.../...

Quoted 6 lines

I dont know what context lead to this observation. However, PAPR mentions the following nomenclature guideline:
"The value of this property shall be of the form: “PowerPC,<name>”, where <name> is the name of the processor chip which may be displayed to the user. <name> shall not contain underscores."

This actually comes from the original Open Firmware binding for PowerPC processors, which PAPR inherits largely from. Thus this naming scheme should apply to all PowerPC processors when a device-tree is involved.

Quoted 2 lines

I think this name guideline will hold good for all PAPR compliant processors.

Also PAPR is not a processor architecture, it's a platform and firmware architecture, so "PAPR-compliant CPU" has little meaning :-)

Cheers,
Ben.

Quoted 46 lines

Quoted 20 lines
Quoted 6 lines
hw/ppc/spapr.c +1 -0
@@ -1315,6 +1325,14 @@ static void ppc_spapr_init(QEMUMachineInitArgs *args)
 
         cpu_model = g_strndup(parent_name,
             strlen(parent_name) - strlen("-" TYPE_POWERPC_CPU));
+
hw/ppc/spapr.c static void ppc_spapr_init(QEMUMachineInitArgs *args) · line 1338
Quoted 10 lines
hw/ppc/spapr.c +7 -0
+        for (i = 0; ppc_cpu_aliases[i].model != NULL; i++) {
+            if (strcmp(ppc_cpu_aliases[i].model, cpu_model) == 0) {
+                g_free(cpu_model);
+                cpu_model = g_strndup(ppc_cpu_aliases[i].alias,
+                                strlen(ppc_cpu_aliases[i].alias));
+            }
+        }
     }
 
     /* Prepare the device tree */
This is still fixing up the name in the wrong place: -cpu POWER7_v2.3 will not get fixed, only -cpu host or KVM's default.
Quoted 7 lines
The solution I had discussed with Alex is the following: When devices need to expose their name to firmware in a special way, we have the DeviceClass::fw_name field. All we have to do is assign it and use it instead of cpu_model if non-NULL, just like we assign DeviceClass::desc. The way to do it would be to extend the family of POWERPC_DEF* macros to specify the additional field on the relevant CPU models.
Would this be the same use-case as reflected by: ppc_cpu_aliases.alias ? If so, do we really need a separate field to convey the same information ?
Quoted 7 lines
Therefore my above question: Would it be sufficient to explicitly name POWER7_v2.3 PowerPC,POWER7 etc. and to drop the upper-casing? Or would we also need to name a CPU such as MPC8572E (random Freescale CPU where I don't know the expected fw_name and that is unlikely to occur/work in sPAPR) "PowerPC,MPC8572E" if someone specified it with -cpu MPC8572E?
If this is not a PAPR-compliant CPU, I dont think the PAPR naming convention is of any good.
I havent worked with non-PAPR cpus. Is the device tree for such CPUs generated by routines in hw/ppc/spapr.c ? Or do they have custom routines to generate appropriate device tree nodes ?
Regards,

Thomas Huth

2013-08-12 19:17 UTC #6 lore raw

Re: [Qemu-devel] [Qemu-ppc] [PATCH 2/2] [v3] target-ppc: Enhance CPU nodes of device tree to be PAPR compliant.

Am Mon, 12 Aug 2013 16:03:24 +1000
schrieb Benjamin Herrenschmidt <[email protected]>:

Quoted 7 lines · Prerna Saxena

.../...
Quoted 3 lines
I dont know what context lead to this observation. However, PAPR mentions the following nomenclature guideline:

Quoted 7 lines

Quoted 3 lines
"The value of this property shall be of the form: “PowerPC,<name>”, where <name> is the name of the processor chip which may be displayed to the user. <name> shall not contain underscores."
This actually comes from the original Open Firmware binding for PowerPC processors, which PAPR inherits largely from. Thus this naming scheme should apply to all PowerPC processors when a device-tree is involved.

Well, I think it should be used when an Open Firmware environment is used. When you boot via ePAPR device tree, the name should be "cpu" instead, according to the ePAPR specification.

Thomas

Benjamin Herrenschmidt

2013-08-12 21:24 UTC #7 lore raw

Re: [Qemu-devel] [Qemu-ppc] [PATCH 2/2] [v3] target-ppc: Enhance CPU nodes of device tree to be PAPR compliant.

Quoted 14 lines · Thomas Huth

Am Mon, 12 Aug 2013 16:03:24 +1000
schrieb Benjamin Herrenschmidt <[email protected]>:
Quoted 11 lines · Prerna Saxena
.../...
Quoted 6 lines
I dont know what context lead to this observation. However, PAPR mentions the following nomenclature guideline:
"The value of this property shall be of the form: “PowerPC,<name>”, where <name> is the name of the processor chip which may be displayed to the user. <name> shall not contain underscores."

Quoted 7 lines

Quoted 3 lines
This actually comes from the original Open Firmware binding for PowerPC processors, which PAPR inherits largely from. Thus this naming scheme should apply to all PowerPC processors when a device-tree is involved.
Well, I think it should be used when an Open Firmware environment is used. When you boot via ePAPR device tree, the name should be "cpu" instead, according to the ePAPR specification.

Yeah well ... this is a gratuituous change in ePAPR, I don't think it matters really what the name is anyway. I'd suggest sticking to the original OF binding.

Ben.

Alexander Graf

2013-08-14 10:18 UTC #8 lore raw

Re: [Qemu-devel] [Qemu-ppc] [PATCH 2/2] [v3] target-ppc: Enhance CPU nodes of device tree to be PAPR compliant.

Quoted 19 lines · Benjamin Herrenschmidt

Quoted 18 lines · Thomas Huth
Am Mon, 12 Aug 2013 16:03:24 +1000
schrieb Benjamin Herrenschmidt <[email protected]>:
Quoted 14 lines · Prerna Saxena
.../...
Quoted 6 lines
I dont know what context lead to this observation. However, PAPR mentions the following nomenclature guideline:
"The value of this property shall be of the form: “PowerPC,<name>”, where <name> is the name of the processor chip which may be displayed to the user. <name> shall not contain underscores."
This actually comes from the original Open Firmware binding for PowerPC processors, which PAPR inherits largely from. Thus this naming scheme should apply to all PowerPC processors when a device-tree is involved.

Quoted 7 lines

Quoted 3 lines
Well, I think it should be used when an Open Firmware environment is used. When you boot via ePAPR device tree, the name should be "cpu" instead, according to the ePAPR specification.
Yeah well ... this is a gratuituous change in ePAPR, I don't think it matters really what the name is anyway. I'd suggest sticking to the original OF binding.

Can't we just include the PowerPC, bit as part of the fw_name field in the class? I don't think we have any CPUs that can be used both in ePAPR and sPAPR environments. So the POWER7 fw_name field would just contain "PowerPC,POWER7" and the device tree creation code merely appends the @%d piece.

Alex

Andreas Färber

2013-08-14 10:31 UTC #9 lore raw

Re: [Qemu-devel] [Qemu-ppc] [PATCH 2/2] [v3] target-ppc: Enhance CPU nodes of device tree to be PAPR compliant.

Am 14.08.2013 12:18, schrieb Alexander Graf:

Quoted 26 lines · Benjamin Herrenschmidt

Quoted 24 lines · Thomas Huth
Quoted 21 lines
Am Mon, 12 Aug 2013 16:03:24 +1000
schrieb Benjamin Herrenschmidt <[email protected]>:
Quoted 7 lines · Prerna Saxena
.../...
Quoted 3 lines
I dont know what context lead to this observation. However, PAPR mentions the following nomenclature guideline:
Quoted 7 lines
Quoted 3 lines
"The value of this property shall be of the form: “PowerPC,<name>”, where <name> is the name of the processor chip which may be displayed to the user. <name> shall not contain underscores."
This actually comes from the original Open Firmware binding for PowerPC processors, which PAPR inherits largely from. Thus this naming scheme should apply to all PowerPC processors when a device-tree is involved.
Well, I think it should be used when an Open Firmware environment is used. When you boot via ePAPR device tree, the name should be "cpu" instead, according to the ePAPR specification.

Quoted 5 lines

Quoted 3 lines
Yeah well ... this is a gratuituous change in ePAPR, I don't think it matters really what the name is anyway. I'd suggest sticking to the original OF binding.
Can't we just include the PowerPC, bit as part of the fw_name field in the class? I don't think we have any CPUs that can be used both in ePAPR and sPAPR environments. So the POWER7 fw_name field would just contain "PowerPC,POWER7" and the device tree creation code merely appends the @%d piece.

That's exactly what my patch series does, just be patient. :)

Andreas

Signature · 2 lines

SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg

Andreas Färber

2013-08-14 11:04 UTC #10 lore raw

Re: [Qemu-devel] [Qemu-ppc] [PATCH 2/2] [v3] target-ppc: Enhance CPU nodes of device tree to be PAPR compliant.

In reply to Alexander Graf

Am 14.08.2013 12:18, schrieb Alexander Graf:

Quoted 1 line

So the POWER7 fw_name field would just contain "PowerPC,POWER7" and the device tree creation code merely appends the @%d piece.

Speaking of POWER7, Paul said that POWER7+ would look like PowerPC,POWER7+@0 but my POWER5+ is /proc/device-tree/cpus/PowerPC,POWER5@0
without the plus.

Could you double-check the name please?

A preview of my patch with "POWER7+" is here:
https://github.com/afaerber/qemu-cpu/commits/spapr

Thanks,
Andreas

Signature · 2 lines

SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg