[PATCH 0/2] ppc: Rename power5+ and power7+ for the new QOM naming rules

[PATCH 0/2] ppc: Rename power5+ and power7+ for the new QOM naming rules

[Thomas Huth]

We can get rid of the "power5+" / "power7+" hack in qom/object.c
by using CPU aliases for those names instead (first patch).

I think in the long run, we should get rid of the names with a "+"
in it completely, so the second patch suggests to deprecate those,
but I'd also be fine if we keep the aliases around, so in that case
please ignore the second patch.

Thomas Huth (2):
  target/ppc/cpu-models: Rename power5+ and power7+ for new QOM naming
    rules
  docs/about: Deprecate the old "power5+" and "power7+" CPU names

 docs/about/deprecated.rst |  9 +++++++++
 hw/ppc/spapr_cpu_core.c   |  4 ++--
 qom/object.c              |  4 ----
 target/ppc/cpu-models.c   | 10 ++++++----
 4 files changed, 17 insertions(+), 10 deletions(-)

-- 
2.43.0

[PATCH 1/2] target/ppc/cpu-models: Rename power5+ and power7+ for new QOM naming rules

[Thomas Huth]

The character "+" is now forbidden in QOM device names (see commit
b447378e1217 - "Limit type names to alphanumerical and some few special
characters"). For the "power5+" and "power7+" CPU names, there is
currently a hack in type_name_is_valid() to still allow them for
compatibility reasons. However, there is a much nicer solution for this:
Simply use aliases! This way we can still support the old names without
the need for the ugly hack in type_name_is_valid().

Signed-off-by: Thomas Huth <thuth@redhat.com>
---
 hw/ppc/spapr_cpu_core.c |  4 ++--
 qom/object.c            |  4 ----
 target/ppc/cpu-models.c | 10 ++++++----
 3 files changed, 8 insertions(+), 10 deletions(-)

diff --git a/hw/ppc/spapr_cpu_core.c b/hw/ppc/spapr_cpu_core.c
index 5aa1ed474a..214b7a03d8 100644
--- a/hw/ppc/spapr_cpu_core.c
+++ b/hw/ppc/spapr_cpu_core.c
@@ -389,9 +389,9 @@ static const TypeInfo spapr_cpu_core_type_infos[] = {
     DEFINE_SPAPR_CPU_CORE_TYPE("970_v2.2"),
     DEFINE_SPAPR_CPU_CORE_TYPE("970mp_v1.0"),
     DEFINE_SPAPR_CPU_CORE_TYPE("970mp_v1.1"),
-    DEFINE_SPAPR_CPU_CORE_TYPE("power5+_v2.1"),
+    DEFINE_SPAPR_CPU_CORE_TYPE("power5plus_v2.1"),
     DEFINE_SPAPR_CPU_CORE_TYPE("power7_v2.3"),
-    DEFINE_SPAPR_CPU_CORE_TYPE("power7+_v2.1"),
+    DEFINE_SPAPR_CPU_CORE_TYPE("power7plus_v2.1"),
     DEFINE_SPAPR_CPU_CORE_TYPE("power8_v2.0"),
     DEFINE_SPAPR_CPU_CORE_TYPE("power8e_v2.1"),
     DEFINE_SPAPR_CPU_CORE_TYPE("power8nvl_v1.0"),
diff --git a/qom/object.c b/qom/object.c
index 654e1afaf2..2c4c64d2b6 100644
--- a/qom/object.c
+++ b/qom/object.c
@@ -160,10 +160,6 @@ static bool type_name_is_valid(const char *name)
 
     /* Allow some legacy names with '+' in it for compatibility reasons */
     if (name[plen] == '+') {
-        if (plen == 6 && g_str_has_prefix(name, "power")) {
-            /* Allow "power5+" and "power7+" CPU names*/
-            return true;
-        }
         if (plen >= 17 && g_str_has_prefix(name, "Sun-UltraSparc-I")) {
             /* Allow "Sun-UltraSparc-IV+" and "Sun-UltraSparc-IIIi+" */
             return true;
diff --git a/target/ppc/cpu-models.c b/target/ppc/cpu-models.c
index 7dbb47de64..6d854bb023 100644
--- a/target/ppc/cpu-models.c
+++ b/target/ppc/cpu-models.c
@@ -716,11 +716,11 @@
                 "PowerPC 970MP v1.0")
     POWERPC_DEF("970mp_v1.1",    CPU_POWERPC_970MP_v11,              970,
                 "PowerPC 970MP v1.1")
-    POWERPC_DEF("power5+_v2.1",  CPU_POWERPC_POWER5P_v21,            POWER5P,
+    POWERPC_DEF("power5plus_v2.1", CPU_POWERPC_POWER5P_v21,          POWER5P,
                 "POWER5+ v2.1")
     POWERPC_DEF("power7_v2.3",   CPU_POWERPC_POWER7_v23,             POWER7,
                 "POWER7 v2.3")
-    POWERPC_DEF("power7+_v2.1",  CPU_POWERPC_POWER7P_v21,            POWER7,
+    POWERPC_DEF("power7plus_v2.1", CPU_POWERPC_POWER7P_v21,          POWER7,
                 "POWER7+ v2.1")
     POWERPC_DEF("power8e_v2.1",  CPU_POWERPC_POWER8E_v21,            POWER8,
                 "POWER8E v2.1")
@@ -902,10 +902,12 @@ PowerPCCPUAlias ppc_cpu_aliases[] = {
     { "970", "970_v2.2" },
     { "970fx", "970fx_v3.1" },
     { "970mp", "970mp_v1.1" },
-    { "power5+", "power5+_v2.1" },
+    { "power5+", "power5plus_v2.1" },
+    { "power5+_v2.1", "power5plus_v2.1" },
     { "power5gs", "power5+_v2.1" },
     { "power7", "power7_v2.3" },
-    { "power7+", "power7+_v2.1" },
+    { "power7+", "power7plus_v2.1" },
+    { "power7+_v2.1", "power7plus_v2.1" },
     { "power8e", "power8e_v2.1" },
     { "power8", "power8_v2.0" },
     { "power8nvl", "power8nvl_v1.0" },
-- 
2.43.0

[PATCH 2/2] docs/about: Deprecate the old "power5+" and "power7+" CPU names

[Thomas Huth]

For consistency we should drop the names with a "+" in it in the
long run.

Signed-off-by: Thomas Huth <thuth@redhat.com>
---
 docs/about/deprecated.rst | 9 +++++++++
 1 file changed, 9 insertions(+)

diff --git a/docs/about/deprecated.rst b/docs/about/deprecated.rst
index 2e15040246..7fdd2239b4 100644
--- a/docs/about/deprecated.rst
+++ b/docs/about/deprecated.rst
@@ -245,6 +245,15 @@ Nios II CPU (since 8.2)
 The Nios II architecture is orphan. The ``nios2`` guest CPU support is
 deprecated and will be removed in a future version of QEMU.
 
+``power5+`` and ``power7+`` CPU names (since 9.0)
+'''''''''''''''''''''''''''''''''''''''''''''''''
+
+The character "+" in device (and thus also CPU) names is not allowed
+in the QEMU object model anymore. ``power5+``, ``power5+_v2.1``,
+``power7+`` and ``power7+_v2.1`` are currently still supported via
+an alias, but for consistency these will get removed in a future
+release, too. Use ``power5plus_v2.1`` and ``power7plus_v2.1`` instead.
+
 
 System emulator machines
 ------------------------
-- 
2.43.0

Re: [PATCH 1/2] target/ppc/cpu-models: Rename power5+ and power7+ for new QOM naming rules

[Cédric Le Goater]

On 1/11/24 17:46, Thomas Huth wrote:
> The character "+" is now forbidden in QOM device names (see commit
> b447378e1217 - "Limit type names to alphanumerical and some few special
> characters"). For the "power5+" and "power7+" CPU names, there is
> currently a hack in type_name_is_valid() to still allow them for
> compatibility reasons. However, there is a much nicer solution for this:
> Simply use aliases! This way we can still support the old names without
> the need for the ugly hack in type_name_is_valid().
> 
> Signed-off-by: Thomas Huth <thuth@redhat.com>


Reviewed-by: Cédric Le Goater <clg@redhat.com>

Thanks,

C.

Re: [PATCH 2/2] docs/about: Deprecate the old "power5+" and "power7+" CPU names

[Cédric Le Goater]

On 1/11/24 17:46, Thomas Huth wrote:
> For consistency we should drop the names with a "+" in it in the
> long run.
> 
> Signed-off-by: Thomas Huth <thuth@redhat.com>
> ---
>   docs/about/deprecated.rst | 9 +++++++++
>   1 file changed, 9 insertions(+)
> 
> diff --git a/docs/about/deprecated.rst b/docs/about/deprecated.rst
> index 2e15040246..7fdd2239b4 100644
> --- a/docs/about/deprecated.rst
> +++ b/docs/about/deprecated.rst
> @@ -245,6 +245,15 @@ Nios II CPU (since 8.2)
>   The Nios II architecture is orphan. The ``nios2`` guest CPU support is
>   deprecated and will be removed in a future version of QEMU.
>   
> +``power5+`` and ``power7+`` CPU names (since 9.0)
> +'''''''''''''''''''''''''''''''''''''''''''''''''
> +
> +The character "+" in device (and thus also CPU) names is not allowed
> +in the QEMU object model anymore. ``power5+``, ``power5+_v2.1``,
> +``power7+`` and ``power7+_v2.1`` are currently still supported via
> +an alias, but for consistency these will get removed in a future
> +release, too. Use ``power5plus_v2.1`` and ``power7plus_v2.1`` instead.
> +
>   
>   System emulator machines
>   ------------------------


Reviewed-by: Cédric Le Goater <clg@redhat.com>

Thanks,

C.

Re: [PATCH 1/2] target/ppc/cpu-models: Rename power5+ and power7+ for new QOM naming rules

[Harsh Prateek Bora]

On 1/11/24 22:16, Thomas Huth wrote:
> The character "+" is now forbidden in QOM device names (see commit
> b447378e1217 - "Limit type names to alphanumerical and some few special
> characters"). For the "power5+" and "power7+" CPU names, there is
> currently a hack in type_name_is_valid() to still allow them for
> compatibility reasons. However, there is a much nicer solution for this:
> Simply use aliases! This way we can still support the old names without
> the need for the ugly hack in type_name_is_valid().
> 
> Signed-off-by: Thomas Huth <thuth@redhat.com>
> ---
>   hw/ppc/spapr_cpu_core.c |  4 ++--
>   qom/object.c            |  4 ----
>   target/ppc/cpu-models.c | 10 ++++++----
>   3 files changed, 8 insertions(+), 10 deletions(-)
> 
> diff --git a/hw/ppc/spapr_cpu_core.c b/hw/ppc/spapr_cpu_core.c
> index 5aa1ed474a..214b7a03d8 100644
> --- a/hw/ppc/spapr_cpu_core.c
> +++ b/hw/ppc/spapr_cpu_core.c
> @@ -389,9 +389,9 @@ static const TypeInfo spapr_cpu_core_type_infos[] = {
>       DEFINE_SPAPR_CPU_CORE_TYPE("970_v2.2"),
>       DEFINE_SPAPR_CPU_CORE_TYPE("970mp_v1.0"),
>       DEFINE_SPAPR_CPU_CORE_TYPE("970mp_v1.1"),
> -    DEFINE_SPAPR_CPU_CORE_TYPE("power5+_v2.1"),
> +    DEFINE_SPAPR_CPU_CORE_TYPE("power5plus_v2.1"),
>       DEFINE_SPAPR_CPU_CORE_TYPE("power7_v2.3"),
> -    DEFINE_SPAPR_CPU_CORE_TYPE("power7+_v2.1"),
> +    DEFINE_SPAPR_CPU_CORE_TYPE("power7plus_v2.1"),

Will using Power5x, Power7x be a better naming than using 'plus' suffix ?

Otherwise,
Reviewed-by: Harsh Prateek Bora <harshpb@linux.ibm.com>

>       DEFINE_SPAPR_CPU_CORE_TYPE("power8_v2.0"),
>       DEFINE_SPAPR_CPU_CORE_TYPE("power8e_v2.1"),
>       DEFINE_SPAPR_CPU_CORE_TYPE("power8nvl_v1.0"),
> diff --git a/qom/object.c b/qom/object.c
> index 654e1afaf2..2c4c64d2b6 100644
> --- a/qom/object.c
> +++ b/qom/object.c
> @@ -160,10 +160,6 @@ static bool type_name_is_valid(const char *name)
>   
>       /* Allow some legacy names with '+' in it for compatibility reasons */
>       if (name[plen] == '+') {
> -        if (plen == 6 && g_str_has_prefix(name, "power")) {
> -            /* Allow "power5+" and "power7+" CPU names*/
> -            return true;
> -        }
>           if (plen >= 17 && g_str_has_prefix(name, "Sun-UltraSparc-I")) {
>               /* Allow "Sun-UltraSparc-IV+" and "Sun-UltraSparc-IIIi+" */
>               return true;
> diff --git a/target/ppc/cpu-models.c b/target/ppc/cpu-models.c
> index 7dbb47de64..6d854bb023 100644
> --- a/target/ppc/cpu-models.c
> +++ b/target/ppc/cpu-models.c
> @@ -716,11 +716,11 @@
>                   "PowerPC 970MP v1.0")
>       POWERPC_DEF("970mp_v1.1",    CPU_POWERPC_970MP_v11,              970,
>                   "PowerPC 970MP v1.1")
> -    POWERPC_DEF("power5+_v2.1",  CPU_POWERPC_POWER5P_v21,            POWER5P,
> +    POWERPC_DEF("power5plus_v2.1", CPU_POWERPC_POWER5P_v21,          POWER5P,
>                   "POWER5+ v2.1")
>       POWERPC_DEF("power7_v2.3",   CPU_POWERPC_POWER7_v23,             POWER7,
>                   "POWER7 v2.3")
> -    POWERPC_DEF("power7+_v2.1",  CPU_POWERPC_POWER7P_v21,            POWER7,
> +    POWERPC_DEF("power7plus_v2.1", CPU_POWERPC_POWER7P_v21,          POWER7,
>                   "POWER7+ v2.1")
>       POWERPC_DEF("power8e_v2.1",  CPU_POWERPC_POWER8E_v21,            POWER8,
>                   "POWER8E v2.1")
> @@ -902,10 +902,12 @@ PowerPCCPUAlias ppc_cpu_aliases[] = {
>       { "970", "970_v2.2" },
>       { "970fx", "970fx_v3.1" },
>       { "970mp", "970mp_v1.1" },
> -    { "power5+", "power5+_v2.1" },
> +    { "power5+", "power5plus_v2.1" },
> +    { "power5+_v2.1", "power5plus_v2.1" },
>       { "power5gs", "power5+_v2.1" },
>       { "power7", "power7_v2.3" },
> -    { "power7+", "power7+_v2.1" },
> +    { "power7+", "power7plus_v2.1" },
> +    { "power7+_v2.1", "power7plus_v2.1" },
>       { "power8e", "power8e_v2.1" },
>       { "power8", "power8_v2.0" },
>       { "power8nvl", "power8nvl_v1.0" },

Re: [PATCH 1/2] target/ppc/cpu-models: Rename power5+ and power7+ for new QOM naming rules

[Thomas Huth]

On 12/01/2024 05.57, Harsh Prateek Bora wrote:
> 
> 
> On 1/11/24 22:16, Thomas Huth wrote:
>> The character "+" is now forbidden in QOM device names (see commit
>> b447378e1217 - "Limit type names to alphanumerical and some few special
>> characters"). For the "power5+" and "power7+" CPU names, there is
>> currently a hack in type_name_is_valid() to still allow them for
>> compatibility reasons. However, there is a much nicer solution for this:
>> Simply use aliases! This way we can still support the old names without
>> the need for the ugly hack in type_name_is_valid().
>>
>> Signed-off-by: Thomas Huth <thuth@redhat.com>
>> ---
>>   hw/ppc/spapr_cpu_core.c |  4 ++--
>>   qom/object.c            |  4 ----
>>   target/ppc/cpu-models.c | 10 ++++++----
>>   3 files changed, 8 insertions(+), 10 deletions(-)
>>
>> diff --git a/hw/ppc/spapr_cpu_core.c b/hw/ppc/spapr_cpu_core.c
>> index 5aa1ed474a..214b7a03d8 100644
>> --- a/hw/ppc/spapr_cpu_core.c
>> +++ b/hw/ppc/spapr_cpu_core.c
>> @@ -389,9 +389,9 @@ static const TypeInfo spapr_cpu_core_type_infos[] = {
>>       DEFINE_SPAPR_CPU_CORE_TYPE("970_v2.2"),
>>       DEFINE_SPAPR_CPU_CORE_TYPE("970mp_v1.0"),
>>       DEFINE_SPAPR_CPU_CORE_TYPE("970mp_v1.1"),
>> -    DEFINE_SPAPR_CPU_CORE_TYPE("power5+_v2.1"),
>> +    DEFINE_SPAPR_CPU_CORE_TYPE("power5plus_v2.1"),
>>       DEFINE_SPAPR_CPU_CORE_TYPE("power7_v2.3"),
>> -    DEFINE_SPAPR_CPU_CORE_TYPE("power7+_v2.1"),
>> +    DEFINE_SPAPR_CPU_CORE_TYPE("power7plus_v2.1"),
> 
> Will using Power5x, Power7x be a better naming than using 'plus' suffix ?

The "x" looks like a placeholder to me, so it could be confused with 
power50, power51, power52, etc. ...?
But actually, I was thinking about using "power5p" and "power7p" first, so 
if the whole "plus" looks too long for you, would "p" be an option instead?

> Otherwise,
> Reviewed-by: Harsh Prateek Bora <harshpb@linux.ibm.com>

Thanks!

  Thomas

Re: [PATCH 1/2] target/ppc/cpu-models: Rename power5+ and power7+ for new QOM naming rules

[Harsh Prateek Bora]

On 1/12/24 10:42, Thomas Huth wrote:
> On 12/01/2024 05.57, Harsh Prateek Bora wrote:
>>
>>
>> On 1/11/24 22:16, Thomas Huth wrote:
>>> The character "+" is now forbidden in QOM device names (see commit
>>> b447378e1217 - "Limit type names to alphanumerical and some few special
>>> characters"). For the "power5+" and "power7+" CPU names, there is
>>> currently a hack in type_name_is_valid() to still allow them for
>>> compatibility reasons. However, there is a much nicer solution for this:
>>> Simply use aliases! This way we can still support the old names without
>>> the need for the ugly hack in type_name_is_valid().
>>>
>>> Signed-off-by: Thomas Huth <thuth@redhat.com>
>>> ---
>>>   hw/ppc/spapr_cpu_core.c |  4 ++--
>>>   qom/object.c            |  4 ----
>>>   target/ppc/cpu-models.c | 10 ++++++----
>>>   3 files changed, 8 insertions(+), 10 deletions(-)
>>>
>>> diff --git a/hw/ppc/spapr_cpu_core.c b/hw/ppc/spapr_cpu_core.c
>>> index 5aa1ed474a..214b7a03d8 100644
>>> --- a/hw/ppc/spapr_cpu_core.c
>>> +++ b/hw/ppc/spapr_cpu_core.c
>>> @@ -389,9 +389,9 @@ static const TypeInfo spapr_cpu_core_type_infos[] 
>>> = {
>>>       DEFINE_SPAPR_CPU_CORE_TYPE("970_v2.2"),
>>>       DEFINE_SPAPR_CPU_CORE_TYPE("970mp_v1.0"),
>>>       DEFINE_SPAPR_CPU_CORE_TYPE("970mp_v1.1"),
>>> -    DEFINE_SPAPR_CPU_CORE_TYPE("power5+_v2.1"),
>>> +    DEFINE_SPAPR_CPU_CORE_TYPE("power5plus_v2.1"),
>>>       DEFINE_SPAPR_CPU_CORE_TYPE("power7_v2.3"),
>>> -    DEFINE_SPAPR_CPU_CORE_TYPE("power7+_v2.1"),
>>> +    DEFINE_SPAPR_CPU_CORE_TYPE("power7plus_v2.1"),
>>
>> Will using Power5x, Power7x be a better naming than using 'plus' suffix ?
> 
> The "x" looks like a placeholder to me, so it could be confused with 
> power50, power51, power52, etc. ...?
> But actually, I was thinking about using "power5p" and "power7p" first, 
> so if the whole "plus" looks too long for you, would "p" be an option 
> instead?

Hmm .. I would certainly vote for 'p' over 'plus'.

regards,
Harsh
> 
>> Otherwise,
>> Reviewed-by: Harsh Prateek Bora <harshpb@linux.ibm.com>
> 
> Thanks!
> 
>   Thomas
> 

Re: [PATCH 1/2] target/ppc/cpu-models: Rename power5+ and power7+ for new QOM naming rules

[Thomas Huth]

On 12/01/2024 06.21, Harsh Prateek Bora wrote:
> 
> 
> On 1/12/24 10:42, Thomas Huth wrote:
>> On 12/01/2024 05.57, Harsh Prateek Bora wrote:
>>>
>>>
>>> On 1/11/24 22:16, Thomas Huth wrote:
>>>> The character "+" is now forbidden in QOM device names (see commit
>>>> b447378e1217 - "Limit type names to alphanumerical and some few special
>>>> characters"). For the "power5+" and "power7+" CPU names, there is
>>>> currently a hack in type_name_is_valid() to still allow them for
>>>> compatibility reasons. However, there is a much nicer solution for this:
>>>> Simply use aliases! This way we can still support the old names without
>>>> the need for the ugly hack in type_name_is_valid().
>>>>
>>>> Signed-off-by: Thomas Huth <thuth@redhat.com>
>>>> ---
>>>>   hw/ppc/spapr_cpu_core.c |  4 ++--
>>>>   qom/object.c            |  4 ----
>>>>   target/ppc/cpu-models.c | 10 ++++++----
>>>>   3 files changed, 8 insertions(+), 10 deletions(-)
>>>>
>>>> diff --git a/hw/ppc/spapr_cpu_core.c b/hw/ppc/spapr_cpu_core.c
>>>> index 5aa1ed474a..214b7a03d8 100644
>>>> --- a/hw/ppc/spapr_cpu_core.c
>>>> +++ b/hw/ppc/spapr_cpu_core.c
>>>> @@ -389,9 +389,9 @@ static const TypeInfo spapr_cpu_core_type_infos[] = {
>>>>       DEFINE_SPAPR_CPU_CORE_TYPE("970_v2.2"),
>>>>       DEFINE_SPAPR_CPU_CORE_TYPE("970mp_v1.0"),
>>>>       DEFINE_SPAPR_CPU_CORE_TYPE("970mp_v1.1"),
>>>> -    DEFINE_SPAPR_CPU_CORE_TYPE("power5+_v2.1"),
>>>> +    DEFINE_SPAPR_CPU_CORE_TYPE("power5plus_v2.1"),
>>>>       DEFINE_SPAPR_CPU_CORE_TYPE("power7_v2.3"),
>>>> -    DEFINE_SPAPR_CPU_CORE_TYPE("power7+_v2.1"),
>>>> +    DEFINE_SPAPR_CPU_CORE_TYPE("power7plus_v2.1"),
>>>
>>> Will using Power5x, Power7x be a better naming than using 'plus' suffix ?
>>
>> The "x" looks like a placeholder to me, so it could be confused with 
>> power50, power51, power52, etc. ...?
>> But actually, I was thinking about using "power5p" and "power7p" first, so 
>> if the whole "plus" looks too long for you, would "p" be an option instead?
> 
> Hmm .. I would certainly vote for 'p' over 'plus'.

Ok, I don't mind either way ... does anybody else have any preferences?

  Thomas

Re: [PATCH 1/2] target/ppc/cpu-models: Rename power5+ and power7+ for new QOM naming rules

[Cédric Le Goater]

On 1/12/24 11:55, Thomas Huth wrote:
> On 12/01/2024 06.21, Harsh Prateek Bora wrote:
>>
>>
>> On 1/12/24 10:42, Thomas Huth wrote:
>>> On 12/01/2024 05.57, Harsh Prateek Bora wrote:
>>>>
>>>>
>>>> On 1/11/24 22:16, Thomas Huth wrote:
>>>>> The character "+" is now forbidden in QOM device names (see commit
>>>>> b447378e1217 - "Limit type names to alphanumerical and some few special
>>>>> characters"). For the "power5+" and "power7+" CPU names, there is
>>>>> currently a hack in type_name_is_valid() to still allow them for
>>>>> compatibility reasons. However, there is a much nicer solution for this:
>>>>> Simply use aliases! This way we can still support the old names without
>>>>> the need for the ugly hack in type_name_is_valid().
>>>>>
>>>>> Signed-off-by: Thomas Huth <thuth@redhat.com>
>>>>> ---
>>>>>   hw/ppc/spapr_cpu_core.c |  4 ++--
>>>>>   qom/object.c            |  4 ----
>>>>>   target/ppc/cpu-models.c | 10 ++++++----
>>>>>   3 files changed, 8 insertions(+), 10 deletions(-)
>>>>>
>>>>> diff --git a/hw/ppc/spapr_cpu_core.c b/hw/ppc/spapr_cpu_core.c
>>>>> index 5aa1ed474a..214b7a03d8 100644
>>>>> --- a/hw/ppc/spapr_cpu_core.c
>>>>> +++ b/hw/ppc/spapr_cpu_core.c
>>>>> @@ -389,9 +389,9 @@ static const TypeInfo spapr_cpu_core_type_infos[] = {
>>>>>       DEFINE_SPAPR_CPU_CORE_TYPE("970_v2.2"),
>>>>>       DEFINE_SPAPR_CPU_CORE_TYPE("970mp_v1.0"),
>>>>>       DEFINE_SPAPR_CPU_CORE_TYPE("970mp_v1.1"),
>>>>> -    DEFINE_SPAPR_CPU_CORE_TYPE("power5+_v2.1"),
>>>>> +    DEFINE_SPAPR_CPU_CORE_TYPE("power5plus_v2.1"),
>>>>>       DEFINE_SPAPR_CPU_CORE_TYPE("power7_v2.3"),
>>>>> -    DEFINE_SPAPR_CPU_CORE_TYPE("power7+_v2.1"),
>>>>> +    DEFINE_SPAPR_CPU_CORE_TYPE("power7plus_v2.1"),
>>>>
>>>> Will using Power5x, Power7x be a better naming than using 'plus' suffix ?
>>>
>>> The "x" looks like a placeholder to me, so it could be confused with power50, power51, power52, etc. ...?
>>> But actually, I was thinking about using "power5p" and "power7p" first, so if the whole "plus" looks too long for you, would "p" be an option instead?
>>
>> Hmm .. I would certainly vote for 'p' over 'plus'.
> 
> Ok, I don't mind either way ... does anybody else have any preferences?

p is fine.


Thanks,

C.

Re: [PATCH 0/2] ppc: Rename power5+ and power7+ for the new QOM naming rules

[Peter Krempa]

On Thu, Jan 11, 2024 at 17:46:50 +0100, Thomas Huth wrote:
> We can get rid of the "power5+" / "power7+" hack in qom/object.c
> by using CPU aliases for those names instead (first patch).
> 
> I think in the long run, we should get rid of the names with a "+"
> in it completely, so the second patch suggests to deprecate those,
> but I'd also be fine if we keep the aliases around, so in that case
> please ignore the second patch.
> 
> Thomas Huth (2):
>   target/ppc/cpu-models: Rename power5+ and power7+ for new QOM naming
>     rules
>   docs/about: Deprecate the old "power5+" and "power7+" CPU names

libvirt seems to be explicitly referencing power7+ in the code, so I
guess we'll need code to translate the + versions to the spellt-out
version to preserve compatibility.

Re: [PATCH 1/2] target/ppc/cpu-models: Rename power5+ and power7+ for new QOM naming rules

[Philippe Mathieu-Daudé]

On 12/1/24 12:33, Cédric Le Goater wrote:
> On 1/12/24 11:55, Thomas Huth wrote:
>> On 12/01/2024 06.21, Harsh Prateek Bora wrote:


>>> Hmm .. I would certainly vote for 'p' over 'plus'.
>>
>> Ok, I don't mind either way ... does anybody else have any preferences?
> 
> p is fine.

We also use 'p' for '+' / 'plus' on ARM Raspberry Pi:

$ qemu-system-aarch64 -M help | grep -F raspi
raspi0               Raspberry Pi Zero (revision 1.2)
raspi1ap             Raspberry Pi A+ (revision 1.1)
raspi2b              Raspberry Pi 2B (revision 1.1)
raspi3ap             Raspberry Pi 3A+ (revision 1.0)
raspi3b              Raspberry Pi 3B (revision 1.2)

Re: [PATCH 0/2] ppc: Rename power5+ and power7+ for the new QOM naming rules

[Thomas Huth]

On 12/01/2024 13.48, Peter Krempa wrote:
> On Thu, Jan 11, 2024 at 17:46:50 +0100, Thomas Huth wrote:
>> We can get rid of the "power5+" / "power7+" hack in qom/object.c
>> by using CPU aliases for those names instead (first patch).
>>
>> I think in the long run, we should get rid of the names with a "+"
>> in it completely, so the second patch suggests to deprecate those,
>> but I'd also be fine if we keep the aliases around, so in that case
>> please ignore the second patch.
>>
>> Thomas Huth (2):
>>    target/ppc/cpu-models: Rename power5+ and power7+ for new QOM naming
>>      rules
>>    docs/about: Deprecate the old "power5+" and "power7+" CPU names
> 
> libvirt seems to be explicitly referencing power7+ in the code, so I
> guess we'll need code to translate the + versions to the spellt-out
> version to preserve compatibility.

If it's too cumbersome, we could also keep the alias enabled in QEMU, i.e. 
drop the second patch...?

  Thomas