Comment 3 for bug 1988527

There are multiple levels this could be going wrong or being a misunderstanding of expectations/behavior.

I assume you didn't hit the obvious, like a permission issue which would appear as:
Could not access KVM kernel module: Permission denied
qemu-system-ppc64: failed to initialize kvm: Permission denied
qemu-system-ppc64: falling back to tcg

In addition please be aware that second level virtualization is known be somewhat dysfunctional and therefore won't work. I assume we have level 1 = openstack providing a Vm for autopkgtest and then level 2 (without options to force it) will default to TCG.
For second level (using kernel kvm_pr instead of kvm_hv) you might always need to force accel=kvm which is just what you have done in your workaround (and maybe need to load kvm_pr manually).

But let us ignore second level for now and resolve the simple case first - running on bare metal.
With the qemu monitors `info jit` you can check if tcg was enabled (not needing to assume it based on speed) and therefore easily check which options lead to tcg being used or if KVM accel is used instead.

Easy cases first - things running as specified:

KVM Mode
$ sudo qemu-system-ppc64 -S -nographic -monitor telnet:127.0.0.1:1234,server,nowait -machine pseries-jammy,accel=kvm:tcg
$ sudo qemu-system-ppc64 -S -nographic -monitor telnet:127.0.0.1:1234,server,nowait -machine pseries-jammy,accel=kvm

TCG Mode
$ sudo qemu-system-ppc64 -S -nographic -monitor telnet:127.0.0.1:1234,server,nowait -machine pseries-jammy,accel=tcg
$ sudo qemu-system-ppc64 -S -nographic -monitor telnet:127.0.0.1:1234,server,nowait -machine pseries-jammy,accel=kvm:tcg:kvm