qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Thomas Huth <thuth@redhat.com>
To: Glenn Miles <milesg@linux.ibm.com>, qemu-devel@nongnu.org
Cc: qemu-ppc@nongnu.org, clg@redhat.com, npiggin@gmail.com,
	harshpb@linux.ibm.com
Subject: Re: [RFC 0/3] Add IBM PPE42 support
Date: Mon, 18 Aug 2025 09:48:36 +0200	[thread overview]
Message-ID: <fe4e09ca-52bb-4af9-9a0b-49aac54d2a37@redhat.com> (raw)
In-Reply-To: <20250814223741.29433-1-milesg@linux.ibm.com>

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



  parent reply	other threads:[~2025-08-18  7:49 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-08-14 22:37 [RFC 0/3] Add IBM PPE42 support Glenn Miles
2025-08-14 22:37 ` [RFC 1/3] target/ppc: Add IBM PPE42 family of processors Glenn Miles
2025-08-14 22:37 ` [RFC 2/3] target/ppc: Add IBM PPE42 special instructions Glenn Miles
2025-08-14 23:12   ` Cédric Le Goater
2025-08-15 14:30   ` Richard Henderson
2025-08-14 22:37 ` [RFC 3/3] hw/ppc: Add a test machine for the IBM PPE42 CPU Glenn Miles
2025-08-18  7:48 ` Thomas Huth [this message]
2025-08-18 15:02   ` [RFC 0/3] Add IBM PPE42 support Miles Glenn

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=fe4e09ca-52bb-4af9-9a0b-49aac54d2a37@redhat.com \
    --to=thuth@redhat.com \
    --cc=clg@redhat.com \
    --cc=harshpb@linux.ibm.com \
    --cc=milesg@linux.ibm.com \
    --cc=npiggin@gmail.com \
    --cc=qemu-devel@nongnu.org \
    --cc=qemu-ppc@nongnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).