I am introducing this patchset as an RFC primarily so that
I can get some advice on how to go about testing this CPU.
Please read on for details...

This patchset adds support for the IBM PPE42 processor,
including a simple machine providing a platform for
testing the PPE42 instructions.

The PPE42 processor is used as an embedded processor 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 and some 64-bit
logical operations.
    
For more information on the PPE 42 processor please visit:
    
https://wiki.raptorcs.com/w/images/a/a3/PPE_42X_Core_Users_Manual.pdf

I have some code that tests the instructions that are
specific to the PPE42.  It is a very basic test written
in assembly.  This can be found at:

https://github.com/milesg-github/ppe42-tests

There is also a prebuilt image there in the images
folder.

Building the image requires a forked version of an old
version of GCC, which can be found here:

https://github.com/open-power/ppe42-gcc

Even though everything that is necessary to build the
image is publicly available, it is not a simple task.
This is why I think it would be best to just use the
prebuilt image available on github instead of trying to
build it.

Also, there is currently no support for having console
output (this is also not supported in the actual HW).
All logging on actual hardware is done using in-memory
trace buffers that requires a special tool for translation
to a human readable format. Because of this, I'm thinking
this is not a good candidate for using the QEMU
"tests/functional" framework, which seems to rely a lot
on console output.

I do think it would be possible to use the qtest framework
to load the image and run it.

The existing test will cause a checkstop if it fails.
This leads to dumping the cpu registers, which aids in
debug.  There is currently no way to tell that the
test completed, other than checking the NIP address,
but this could be easily remedied by having the guest
code write some status to a fixed memory address and
then having the qtest code poll that memory address
to determine that the test completed within some reasonable
timeout period.

The one thing that I'm not sure about with using the
qtest framework is how to retrieve the image. If anyone
has suggestions or examples of that being done for a qtest,
please do share!

Also, if you think there is a better way to do this instead
of using qtest, please let me know.

Thanks,

Glenn

Glenn Miles (3):
  target/ppc: Add IBM PPE42 family of processors
  target/ppc: Add IBM PPE42 special instructions
  hw/ppc: Add a test machine for the IBM PPE42 CPU

 hw/ppc/Kconfig                      |   9 +
 hw/ppc/meson.build                  |   2 +
 hw/ppc/ppc_booke.c                  |   7 +-
 hw/ppc/ppe42_machine.c              |  69 +++
 include/hw/ppc/ppc.h                |   1 +
 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            |  30 +-
 target/ppc/insn32.decode            |  66 ++-
 target/ppc/tcg-excp_helper.c        |  12 +
 target/ppc/translate.c              |  35 +-
 target/ppc/translate/ppe-impl.c.inc | 805 ++++++++++++++++++++++++++++
 15 files changed, 1514 insertions(+), 56 deletions(-)
 create mode 100644 hw/ppc/ppe42_machine.c
 create mode 100644 target/ppc/translate/ppe-impl.c.inc

-- 
2.43.0

On 15/08/2025 00.37, Glenn Miles wrote:
...
> I have some code that tests the instructions that are
> specific to the PPE42.  It is a very basic test written
> in assembly.  This can be found at:
> 
> https://github.com/milesg-github/ppe42-tests
> 
> There is also a prebuilt image there in the images
> folder.
> 
> Building the image requires a forked version of an old
> version of GCC, which can be found here:
> 
> https://github.com/open-power/ppe42-gcc
> 
> Even though everything that is necessary to build the
> image is publicly available, it is not a simple task.
> This is why I think it would be best to just use the
> prebuilt image available on github instead of trying to
> build it.

With the compiler being not available in the major distros, the idea with 
the prebuilt image is better indeed.

> Also, there is currently no support for having console
> output (this is also not supported in the actual HW).
> All logging on actual hardware is done using in-memory
> trace buffers that requires a special tool for translation
> to a human readable format. Because of this, I'm thinking
> this is not a good candidate for using the QEMU
> "tests/functional" framework, which seems to rely a lot
> on console output.
> 
> I do think it would be possible to use the qtest framework
> to load the image and run it.
> 
> The existing test will cause a checkstop if it fails.
> This leads to dumping the cpu registers, which aids in
> debug.  There is currently no way to tell that the
> test completed, other than checking the NIP address,
> but this could be easily remedied by having the guest
> code write some status to a fixed memory address and
> then having the qtest code poll that memory address
> to determine that the test completed within some reasonable
> timeout period.
> 
> The one thing that I'm not sure about with using the
> qtest framework is how to retrieve the image. If anyone
> has suggestions or examples of that being done for a qtest,
> please do share!

The qtest framework does not have any support for downloading images. I 
think you're way better off using the functional framework for this. The 
console output is just optional there, so if your image does not have any 
serial console output, there are still other means of checking for success.

For example, if you can be sure that a successful test always ends up with a 
certain NIP, you could use

  output = vm.cmd('human-monitor-command', command_line='info registers')

to check the current status of the registers and check the NIP there.

And assuming that a checkstop will cause a QMP event, you could likely also 
use one of the event functions from python/qemu/machine/machine.py to check 
for a failure while waiting for the right NIP.

  HTH,
   Thomas

On Mon, 2025-08-18 at 09:48 +0200, Thomas Huth wrote:
> On 15/08/2025 00.37, Glenn Miles wrote:
> ...
> > I have some code that tests the instructions that are
> > specific to the PPE42.  It is a very basic test written
> > in assembly.  This can be found at:
> > 
> > https://github.com/milesg-github/ppe42-tests
> > 
> > There is also a prebuilt image there in the images
> > folder.
> > 
> > Building the image requires a forked version of an old
> > version of GCC, which can be found here:
> > 
> > https://github.com/open-power/ppe42-gcc
> > 
> > Even though everything that is necessary to build the
> > image is publicly available, it is not a simple task.
> > This is why I think it would be best to just use the
> > prebuilt image available on github instead of trying to
> > build it.
> 
> With the compiler being not available in the major distros, the idea with 
> the prebuilt image is better indeed.
> 
> > Also, there is currently no support for having console
> > output (this is also not supported in the actual HW).
> > All logging on actual hardware is done using in-memory
> > trace buffers that requires a special tool for translation
> > to a human readable format. Because of this, I'm thinking
> > this is not a good candidate for using the QEMU
> > "tests/functional" framework, which seems to rely a lot
> > on console output.
> > 
> > I do think it would be possible to use the qtest framework
> > to load the image and run it.
> > 
> > The existing test will cause a checkstop if it fails.
> > This leads to dumping the cpu registers, which aids in
> > debug.  There is currently no way to tell that the
> > test completed, other than checking the NIP address,
> > but this could be easily remedied by having the guest
> > code write some status to a fixed memory address and
> > then having the qtest code poll that memory address
> > to determine that the test completed within some reasonable
> > timeout period.
> > 
> > The one thing that I'm not sure about with using the
> > qtest framework is how to retrieve the image. If anyone
> > has suggestions or examples of that being done for a qtest,
> > please do share!
> 
> The qtest framework does not have any support for downloading images. I 
> think you're way better off using the functional framework for this. The 
> console output is just optional there, so if your image does not have any 
> serial console output, there are still other means of checking for success.
> 
> For example, if you can be sure that a successful test always ends up with a 
> certain NIP, you could use
> 
>   output = vm.cmd('human-monitor-command', command_line='info registers')
> 
> to check the current status of the registers and check the NIP there.
> 
> And assuming that a checkstop will cause a QMP event, you could likely also 
> use one of the event functions from python/qemu/machine/machine.py to check 
> for a failure while waiting for the right NIP.
> 
>   HTH,
>    Thomas
> 

Thanks for the tip, Thomas!  I will give that a try.

Glenn