ppc: Drop support for POWER9 and POWER10 DD1 chips

The POWER9 DD1 and POWER10 DD1 chips are not public and are no longer of
any use in QEMU. Remove them.

Reviewed-by: Harsh Prateek Bora <harshpb@li

ppc: Drop support for POWER9 and POWER10 DD1 chips

The POWER9 DD1 and POWER10 DD1 chips are not public and are no longer of
any use in QEMU. Remove them.

Reviewed-by: Harsh Prateek Bora <harshpb@linux.ibm.com>
Signed-off-by: Nicholas Piggin <npiggin@gmail.com>

show more ...

spapr: set MSR[ME] and MSR[FP] on client entry

The initial MSR state for the OpenFirmware binding specifies
MSR[ME] and MSR[FP] are set.

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

spapr: set MSR[ME] and MSR[FP] on client entry

The initial MSR state for the OpenFirmware binding specifies
MSR[ME] and MSR[FP] are set.

Reviewed-by: Harsh Prateek Bora <harshpb@linux.ibm.com>
Signed-off-by: Nicholas Piggin <npiggin@gmail.com>

show more ...

ppc: Drop support for POWER9 and POWER10 DD1 chips

The POWER9 DD1 and POWER10 DD1 chips are not public and are no longer of
any use in QEMU. Remove them.

Reviewed-by: Harsh Prateek Bora <harshpb@li

ppc: Drop support for POWER9 and POWER10 DD1 chips

The POWER9 DD1 and POWER10 DD1 chips are not public and are no longer of
any use in QEMU. Remove them.

Reviewed-by: Harsh Prateek Bora <harshpb@linux.ibm.com>
Signed-off-by: Nicholas Piggin <npiggin@gmail.com>

show more ...

spapr: set MSR[ME] and MSR[FP] on client entry

The initial MSR state for the OpenFirmware binding specifies
MSR[ME] and MSR[FP] are set.

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

spapr: set MSR[ME] and MSR[FP] on client entry

The initial MSR state for the OpenFirmware binding specifies
MSR[ME] and MSR[FP] are set.

Reviewed-by: Harsh Prateek Bora <harshpb@linux.ibm.com>
Signed-off-by: Nicholas Piggin <npiggin@gmail.com>

show more ...

ppc: Drop support for POWER9 and POWER10 DD1 chips

The POWER9 DD1 and POWER10 DD1 chips are not public and are no longer of
any use in QEMU. Remove them.

Reviewed-by: Harsh Prateek Bora <harshpb@li

ppc: Drop support for POWER9 and POWER10 DD1 chips

The POWER9 DD1 and POWER10 DD1 chips are not public and are no longer of
any use in QEMU. Remove them.

Reviewed-by: Harsh Prateek Bora <harshpb@linux.ibm.com>
Signed-off-by: Nicholas Piggin <npiggin@gmail.com>

show more ...

spapr: set MSR[ME] and MSR[FP] on client entry

The initial MSR state for the OpenFirmware binding specifies
MSR[ME] and MSR[FP] are set.

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

spapr: set MSR[ME] and MSR[FP] on client entry

The initial MSR state for the OpenFirmware binding specifies
MSR[ME] and MSR[FP] are set.

Reviewed-by: Harsh Prateek Bora <harshpb@linux.ibm.com>
Signed-off-by: Nicholas Piggin <npiggin@gmail.com>

show more ...

ppc: Drop support for POWER9 and POWER10 DD1 chips

The POWER9 DD1 and POWER10 DD1 chips are not public and are no longer of
any use in QEMU. Remove them.

Reviewed-by: Harsh Prateek Bora <harshpb@li

ppc: Drop support for POWER9 and POWER10 DD1 chips

The POWER9 DD1 and POWER10 DD1 chips are not public and are no longer of
any use in QEMU. Remove them.

Reviewed-by: Harsh Prateek Bora <harshpb@linux.ibm.com>
Signed-off-by: Nicholas Piggin <npiggin@gmail.com>

show more ...

spapr: set MSR[ME] and MSR[FP] on client entry

The initial MSR state for the OpenFirmware binding specifies
MSR[ME] and MSR[FP] are set.

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

spapr: set MSR[ME] and MSR[FP] on client entry

The initial MSR state for the OpenFirmware binding specifies
MSR[ME] and MSR[FP] are set.

Reviewed-by: Harsh Prateek Bora <harshpb@linux.ibm.com>
Signed-off-by: Nicholas Piggin <npiggin@gmail.com>

show more ...

ppc: Drop support for POWER9 and POWER10 DD1 chips

The POWER9 DD1 and POWER10 DD1 chips are not public and are no longer of
any use in QEMU. Remove them.

Reviewed-by: Harsh Prateek Bora <harshpb@li

ppc: Drop support for POWER9 and POWER10 DD1 chips

The POWER9 DD1 and POWER10 DD1 chips are not public and are no longer of
any use in QEMU. Remove them.

Reviewed-by: Harsh Prateek Bora <harshpb@linux.ibm.com>
Signed-off-by: Nicholas Piggin <npiggin@gmail.com>

show more ...

spapr: set MSR[ME] and MSR[FP] on client entry

The initial MSR state for the OpenFirmware binding specifies
MSR[ME] and MSR[FP] are set.

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

spapr: set MSR[ME] and MSR[FP] on client entry

The initial MSR state for the OpenFirmware binding specifies
MSR[ME] and MSR[FP] are set.

Reviewed-by: Harsh Prateek Bora <harshpb@linux.ibm.com>
Signed-off-by: Nicholas Piggin <npiggin@gmail.com>

show more ...

hw/ppc/spapr_cpu: Use qdev_is_realized() instead of QOM API

Prefer QDev API for QDev objects, avoid the underlying QOM layer.

Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Reviewed-by:

hw/ppc/spapr_cpu: Use qdev_is_realized() instead of QOM API

Prefer QDev API for QDev objects, avoid the underlying QOM layer.

Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Reviewed-by: Zhao Liu <zhao1.liu@intel.com>
Message-Id: <20240216110313.17039-4-philmd@linaro.org>

show more ...

target/ppc/cpu-models: Rename power5+ and power7+ for new QOM naming rules

The character "+" is now forbidden in QOM device names (see commit
b447378e1217 - "Limit type names to alphanumerical and s

target/ppc/cpu-models: Rename power5+ and power7+ for new QOM naming rules

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().

Message-ID: <20240117141054.73841-2-thuth@redhat.com>
Reviewed-by: Cédric Le Goater <clg@kaod.org>
Reviewed-by: Harsh Prateek Bora <harshpb@linux.ibm.com>
Signed-off-by: Thomas Huth <thuth@redhat.com>

show more ...

hw/ppc/spapr_cpu_core: Access QDev properties with proper API

CPUState::start_powered_off field is part of the internal
implementation of a QDev CPU. It is exposed as the QDev
"start-powered-off" pr

hw/ppc/spapr_cpu_core: Access QDev properties with proper API

CPUState::start_powered_off field is part of the internal
implementation of a QDev CPU. It is exposed as the QDev
"start-powered-off" property. External components should
use the qdev properties API to access it.

Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Reviewed-by: Harsh Prateek Bora <harshpb@linux.ibm.com>
Message-Id: <20231123143813.42632-2-philmd@linaro.org>

show more ...

hw/ppc: Constify VMState

Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
Message-Id: <20231221031652.119827-48-richard.henderson@linaro.org>

hw/ppc: Reset timebase facilities on machine reset

Lower interrupts, delete timers, and set time facility registers
back to initial state on machine reset.

This is not so important for record-repla

hw/ppc: Reset timebase facilities on machine reset

Lower interrupts, delete timers, and set time facility registers
back to initial state on machine reset.

This is not so important for record-replay since timebase and
decrementer are migrated, but it gives a cleaner reset state.

Cc: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk>
Cc: BALATON Zoltan <balaton@eik.bme.hu>
Signed-off-by: Nicholas Piggin <npiggin@gmail.com>
[ clg: checkpatch.pl fixes ]
Signed-off-by: Cédric Le Goater <clg@kaod.org>

show more ...

hw/ppc: Reset timebase facilities on machine reset

Lower interrupts, delete timers, and set time facility registers
back to initial state on machine reset.

This is not so important for record-repla

hw/ppc: Reset timebase facilities on machine reset

Lower interrupts, delete timers, and set time facility registers
back to initial state on machine reset.

This is not so important for record-replay since timebase and
decrementer are migrated, but it gives a cleaner reset state.

Cc: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk>
Cc: BALATON Zoltan <balaton@eik.bme.hu>
Signed-off-by: Nicholas Piggin <npiggin@gmail.com>
[ clg: checkpatch.pl fixes ]
Signed-off-by: Cédric Le Goater <clg@kaod.org>

show more ...

target/ppc: Add LPAR-per-core vs per-thread mode flag

The Power ISA has the concept of sub-processors:

Hardware is allowed to sub-divide a multi-threaded processor into
"sub-processors" that ap

target/ppc: Add LPAR-per-core vs per-thread mode flag

The Power ISA has the concept of sub-processors:

Hardware is allowed to sub-divide a multi-threaded processor into
"sub-processors" that appear to privileged programs as multi-threaded
processors with fewer threads.

POWER9 and POWER10 have two modes, either every thread is a
sub-processor or all threads appear as one multi-threaded processor. In
the user manuals these are known as "LPAR per thread" / "Thread LPAR",
and "LPAR per core" / "1 LPAR", respectively.

The practical difference is: in thread LPAR mode, non-hypervisor SPRs
are not shared between threads and msgsndp can not be used to message
siblings. In 1 LPAR mode, some SPRs are shared and msgsndp is usable.
Thrad LPAR allows multiple partitions to run concurrently on the same
core, and is a requirement for KVM to run on POWER9/10 (which does not
gang-schedule an LPAR on all threads of a core like POWER8 KVM).

Traditionally, SMT in PAPR environments including PowerVM and the
pseries QEMU machine with KVM acceleration behaves as in 1 LPAR mode.
In OPAL systems, Thread LPAR is used. When adding SMT to the powernv
machine, it is therefore preferable to emulate Thread LPAR.

To account for this difference between pseries and powernv, an LPAR mode
flag is added such that SPRs can be implemented as per-LPAR shared, and
that becomes either per-thread or per-core depending on the flag.

Reviewed-by: Joel Stanley <joel@jms.id.au>
Reviewed-by: Cédric Le Goater <clg@kaod.org>
Tested-by: Cédric Le Goater <clg@kaod.org>
Signed-off-by: Nicholas Piggin <npiggin@gmail.com>
Message-ID: <20230705120631.27670-2-npiggin@gmail.com>
Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com>

show more ...

target/ppc: Add LPAR-per-core vs per-thread mode flag

The Power ISA has the concept of sub-processors:

Hardware is allowed to sub-divide a multi-threaded processor into
"sub-processors" that ap

target/ppc: Add LPAR-per-core vs per-thread mode flag

The Power ISA has the concept of sub-processors:

Hardware is allowed to sub-divide a multi-threaded processor into
"sub-processors" that appear to privileged programs as multi-threaded
processors with fewer threads.

POWER9 and POWER10 have two modes, either every thread is a
sub-processor or all threads appear as one multi-threaded processor. In
the user manuals these are known as "LPAR per thread" / "Thread LPAR",
and "LPAR per core" / "1 LPAR", respectively.

The practical difference is: in thread LPAR mode, non-hypervisor SPRs
are not shared between threads and msgsndp can not be used to message
siblings. In 1 LPAR mode, some SPRs are shared and msgsndp is usable.
Thrad LPAR allows multiple partitions to run concurrently on the same
core, and is a requirement for KVM to run on POWER9/10 (which does not
gang-schedule an LPAR on all threads of a core like POWER8 KVM).

Traditionally, SMT in PAPR environments including PowerVM and the
pseries QEMU machine with KVM acceleration behaves as in 1 LPAR mode.
In OPAL systems, Thread LPAR is used. When adding SMT to the powernv
machine, it is therefore preferable to emulate Thread LPAR.

To account for this difference between pseries and powernv, an LPAR mode
flag is added such that SPRs can be implemented as per-LPAR shared, and
that becomes either per-thread or per-core depending on the flag.

Reviewed-by: Joel Stanley <joel@jms.id.au>
Reviewed-by: Cédric Le Goater <clg@kaod.org>
Tested-by: Cédric Le Goater <clg@kaod.org>
Signed-off-by: Nicholas Piggin <npiggin@gmail.com>
Message-ID: <20230705120631.27670-2-npiggin@gmail.com>
Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com>

show more ...

target/ppc: Add LPAR-per-core vs per-thread mode flag

The Power ISA has the concept of sub-processors:

Hardware is allowed to sub-divide a multi-threaded processor into
"sub-processors" that ap

target/ppc: Add LPAR-per-core vs per-thread mode flag

The Power ISA has the concept of sub-processors:

Hardware is allowed to sub-divide a multi-threaded processor into
"sub-processors" that appear to privileged programs as multi-threaded
processors with fewer threads.

POWER9 and POWER10 have two modes, either every thread is a
sub-processor or all threads appear as one multi-threaded processor. In
the user manuals these are known as "LPAR per thread" / "Thread LPAR",
and "LPAR per core" / "1 LPAR", respectively.

The practical difference is: in thread LPAR mode, non-hypervisor SPRs
are not shared between threads and msgsndp can not be used to message
siblings. In 1 LPAR mode, some SPRs are shared and msgsndp is usable.
Thrad LPAR allows multiple partitions to run concurrently on the same
core, and is a requirement for KVM to run on POWER9/10 (which does not
gang-schedule an LPAR on all threads of a core like POWER8 KVM).

Traditionally, SMT in PAPR environments including PowerVM and the
pseries QEMU machine with KVM acceleration behaves as in 1 LPAR mode.
In OPAL systems, Thread LPAR is used. When adding SMT to the powernv
machine, it is therefore preferable to emulate Thread LPAR.

To account for this difference between pseries and powernv, an LPAR mode
flag is added such that SPRs can be implemented as per-LPAR shared, and
that becomes either per-thread or per-core depending on the flag.

Reviewed-by: Joel Stanley <joel@jms.id.au>
Reviewed-by: Cédric Le Goater <clg@kaod.org>
Tested-by: Cédric Le Goater <clg@kaod.org>
Signed-off-by: Nicholas Piggin <npiggin@gmail.com>
Message-ID: <20230705120631.27670-2-npiggin@gmail.com>
Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com>

show more ...

spapr: TCG allow up to 8-thread SMT on POWER8 and newer CPUs

PPC TCG supports SMT CPU configurations for non-hypervisor state, so
permit POWER8-10 pseries machines to enable SMT.

This requires PIR

spapr: TCG allow up to 8-thread SMT on POWER8 and newer CPUs

PPC TCG supports SMT CPU configurations for non-hypervisor state, so
permit POWER8-10 pseries machines to enable SMT.

This requires PIR and TIR be set, because that's how sibling thread
matching is done by TCG.

spapr's nested-HV capability does not currently coexist with SMT, so
that combination is prohibited (interestingly somewhat analogous to
LPAR-per-core mode on real hardware which also does not support KVM).

Signed-off-by: Nicholas Piggin <npiggin@gmail.com>
Reviewed-by: Cédric Le Goater <clg@kaod.org>
[ clg: Also test smp_threads when checking for POWER8 CPU and above ]
Signed-off-by: Cédric Le Goater <clg@kaod.org>

show more ...

spapr: TCG allow up to 8-thread SMT on POWER8 and newer CPUs

PPC TCG supports SMT CPU configurations for non-hypervisor state, so
permit POWER8-10 pseries machines to enable SMT.

This requires PIR

spapr: TCG allow up to 8-thread SMT on POWER8 and newer CPUs

PPC TCG supports SMT CPU configurations for non-hypervisor state, so
permit POWER8-10 pseries machines to enable SMT.

This requires PIR and TIR be set, because that's how sibling thread
matching is done by TCG.

spapr's nested-HV capability does not currently coexist with SMT, so
that combination is prohibited (interestingly somewhat analogous to
LPAR-per-core mode on real hardware which also does not support KVM).

Signed-off-by: Nicholas Piggin <npiggin@gmail.com>
Reviewed-by: Cédric Le Goater <clg@kaod.org>
[ clg: Also test smp_threads when checking for POWER8 CPU and above ]
Signed-off-by: Cédric Le Goater <clg@kaod.org>

show more ...

target/ppc: Add POWER9 DD2.2 model

POWER9 DD2.1 and earlier had significant limitations when running KVM,
including lack of "mixed mode" MMU support (ability to run HPT and RPT
mode on threads of th

target/ppc: Add POWER9 DD2.2 model

POWER9 DD2.1 and earlier had significant limitations when running KVM,
including lack of "mixed mode" MMU support (ability to run HPT and RPT
mode on threads of the same core), and a translation prefetch issue
which is worked around by disabling "AIL" mode for the guest.

These processors are not widely available, and it's difficult to deal
with all these quirks in qemu +/- KVM, so create a POWER9 DD2.2 CPU
and make it the default POWER9 CPU.

Signed-off-by: Nicholas Piggin <npiggin@gmail.com>
Reviewed-by: Frederic Barrat <fbarrat@linux.ibm.com>
Reviewed-by: Harsh Prateek Bora <harshpb@linux.ibm.com>
Message-Id: <20230515160201.394587-1-npiggin@gmail.com>
Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com>

show more ...

hw/ppc: free env->tb_env in spapr_unrealize_vcpu()

The timebase is allocated during spapr_realize_vcpu() and it's not
freed. This results in memory leaks when doing vcpu unplugs:

==636935==
==63693

hw/ppc: free env->tb_env in spapr_unrealize_vcpu()

The timebase is allocated during spapr_realize_vcpu() and it's not
freed. This results in memory leaks when doing vcpu unplugs:

==636935==
==636935== 144 (96 direct, 48 indirect) bytes in 1 blocks are definitely lost in loss record 6
,461 of 8,135
==636935== at 0x4897468: calloc (vg_replace_malloc.c:760)
==636935== by 0x5077213: g_malloc0 (in /usr/lib64/libglib-2.0.so.0.6400.4)
==636935== by 0x507757F: g_malloc0_n (in /usr/lib64/libglib-2.0.so.0.6400.4)
==636935== by 0x93C3FB: cpu_ppc_tb_init (ppc.c:1066)
==636935== by 0x97BC2B: spapr_realize_vcpu (spapr_cpu_core.c:268)
==636935== by 0x97C01F: spapr_cpu_core_realize (spapr_cpu_core.c:337)
==636935== by 0xD4626F: device_set_realized (qdev.c:531)
==636935== by 0xD55273: property_set_bool (object.c:2273)
==636935== by 0xD523DF: object_property_set (object.c:1408)
==636935== by 0xD588B7: object_property_set_qobject (qom-qobject.c:28)
==636935== by 0xD52897: object_property_set_bool (object.c:1477)
==636935== by 0xD4579B: qdev_realize (qdev.c:333)
==636935==

This patch adds a cpu_ppc_tb_free() helper in hw/ppc/ppc.c to allow us
to free the timebase. This leak is then solved by calling
cpu_ppc_tb_free() in spapr_unrealize_vcpu().

Fixes: 6f4b5c3ec590 ("spapr: CPU hot unplug support")
Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com>
Reviewed-by: Cédric Le Goater <clg@kaod.org>
Reviewed-by: David Gibson <david@gibson.dropbear.id.au>
Message-Id: <20220329124545.529145-2-danielhb413@gmail.com>
Signed-off-by: Cédric Le Goater <clg@kaod.org>

show more ...

spapr: prevent hdec timer being set up under virtual hypervisor

The spapr virtual hypervisor does not require the hdecr timer.
Remove it.

Reviewed-by: Daniel Henrique Barboza <danielhb413@gmail.com

spapr: prevent hdec timer being set up under virtual hypervisor

The spapr virtual hypervisor does not require the hdecr timer.
Remove it.

Reviewed-by: Daniel Henrique Barboza <danielhb413@gmail.com>
Reviewed-by: Cédric Le Goater <clg@kaod.org>
Signed-off-by: Nicholas Piggin <npiggin@gmail.com>
Message-Id: <20220216102545.1808018-3-npiggin@gmail.com>
Signed-off-by: Cédric Le Goater <clg@kaod.org>

show more ...

spapr: Force 32bit when resetting a core

"PowerPC Processor binding to IEEE 1275" says in
"8.2.1. Initial Register Values" that the initial state is defined as
32bit so do it for both SLOF and VOF.

spapr: Force 32bit when resetting a core

"PowerPC Processor binding to IEEE 1275" says in
"8.2.1. Initial Register Values" that the initial state is defined as
32bit so do it for both SLOF and VOF.

This should not cause behavioral change as SLOF switches to 64bit very
early anyway. As nothing enforces LE anywhere, this drops it for VOF.

The goal is to make VOF work with TCG as otherwise it barfs with
qemu: fatal: TCG hflags mismatch (current:0x6c000004 rebuilt:0x6c000000)

Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru>
Reviewed-by: Cédric Le Goater <clg@kaod.org>
Message-Id: <20220107072423.2278113-1-aik@ozlabs.ru>
Signed-off-by: Cédric Le Goater <clg@kaod.org>

show more ...