Hi Thomas,
On 8/25/25 17:04, Thomas Huth wrote:
On 25/08/2025 13.24, Harsh Prateek Bora wrote:
Hi Glenn,
This seems significant work. Thanks for upstreaming.
On 8/20/25 02:58, Glenn Miles wrote:
Adds the IBM PPE42 family of processors supporting the
family of 32-bit processors ?
PPE42, PPE42X and PPE42XM processor versions. These
processors are used as embedded processors in the IBM
Power9, Power10 and Power12 processors for various
tasks. It is basically a stripped down version of the
IBM PowerPC 405 processor, with some added instructions
for handling 64-bit loads and stores.
For more information on the PPE 42 processor please visit:
https://wiki.raptorcs.com/w/images/a/a3/PPE_42X_Core_Users_Manual.pdf
Supports PPE42 SPR's (Including the MSR) and Exceptions.
Does not yet support new PPE42 instructions and does not
prevent access to some invalid instructions and registers
(currently allows for access to invalid GPR's and CR fields).
Signed-off-by: Glenn Miles <mil...@linux.ibm.com>
---
target/ppc/cpu-models.c | 7 +
target/ppc/cpu-models.h | 4 +
target/ppc/cpu.h | 66 +++++++-
target/ppc/cpu_init.c | 286 ++++++++++++++++++++++++++++++-----
target/ppc/excp_helper.c | 171 +++++++++++++++++++++
target/ppc/helper_regs.c | 28 +++-
target/ppc/tcg-excp_helper.c | 12 ++
target/ppc/translate.c | 6 +-
8 files changed, 535 insertions(+), 45 deletions(-)
diff --git a/target/ppc/cpu-models.c b/target/ppc/cpu-models.c
index ea86ea202a..09f73e23a8 100644
--- a/target/ppc/cpu-models.c
+++ b/target/ppc/cpu-models.c
@@ -116,6 +116,13 @@
NULL)
POWERPC_DEF("x2vp20",
CPU_POWERPC_X2VP20, 405,
NULL)
+ /* PPE42 Embedded
Controllers */
+ POWERPC_DEF("PPE42", CPU_POWERPC_PPE42,
ppe42,
+ "Generic PPE 42")
+ POWERPC_DEF("PPE42X", CPU_POWERPC_PPE42X,
ppe42x,
+ "Generic PPE 42X")
+ POWERPC_DEF("PPE42XM", CPU_POWERPC_PPE42XM, ppe42xm,
+ "Generic PPE 42XM")
Can all the PPE42 specific code be conditionally compiled only for
!TARGET_PPC64 (and !CONFIG_USER_ONLY wherever possible)?
Not only to reduce the bloating size of respective binaries, but also to
avoid some code being added to hot path routines like
hreg_compute_hflags_value().
qemu-system-ppc64 is a superset of qemu-system-ppc, and there are even
efforts to unify all system functionality into a singly binary, so
excluding a 32-bit feature from qemu-system-ppc64 sounds like a step
into the wrong direction to me right now...?
We do have existing code getting conditionally compiled for TARGET_PPC64
which I guess gets enabled with:
--configure target-list=<ppc64|ppc>-softmmu
I understand the efforts are towards having a single binary to support
both, but what gets built-in is still decided with configure choice?
Please correct/clarify with above understanding.
regards,
Harsh
Thomas
