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
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" },
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
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
>
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
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.
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)
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. _______________________________________________ Devel mailing list -- devel@lists.libvirt.org To unsubscribe send an email to devel-leave@lists.libvirt.org
© 2016 - 2026 Red Hat, Inc.