вс, 14 июн. 2026 г., 17:29 BALATON Zoltan [off-list ref]:

On Sun, 14 Jun 2026, Andrew Randrianasulu wrote:

quoted

I tried qemu 10.0.10 (qemu-system-ppc) compiled as ppc32 binary - fail

I tried qemu 2.2.0 compiled as ppc64 binary (qemu-system-ppc and ppc64
variants) -fail

I tried qemu 5.0.0 compiled as 32bit ppc (qemu-system-ppc) - fail.

I tried qemu 6.1.1 compiled as 32bit ppc binary - qemu-system-ppc. Fail.

I tried recompiling host kernel without preemtion - still fail.

:(

fail like this in dmesg

[75573.287328] Couldn't emulate instruction 0x00000000 (op 0 xop 0)
                       [75573.287334] kvmppc_exit_pr_progint: emulation

at

quoted

100 failed (00000000)


lscpu output:
Architecture:                ppc64

CPU op-mode(s):            32-bit, 64-bit
Byte Order:                Big Endian
CPU(s):                      2

On-line CPU(s) list:       0,1

Model name:                  PPC970MP, altivec supported
Model:                     1.1 (pvr 0044 0101)

[...]

quoted

Why so old qemu? Well, it worked on OSX Leopard 10.5.8 on same machine,

so

quoted

I compiled it as 64bit ppc64 binary - new qemu grow a lot  ... and

keeping

quoted

effectively 3 different dev systems makes this 160 gb hdd look small :)

I don't know about it but I think the only combination that ever worked
was ppc on ppc (i.e. KVM on G4 Macs) or maybe ppc64 on ppc64. Running ppc
on ppc64 is known not to work and I haven't heard about anybody fixing
that. There was a blog entry about running MacOS on Power10:

https://www.talospace.com/2018/08/making-your-talos-ii-into-power-mac_29.html
but I think that was on ppc64le (which does not work on G5 as that's big
endian only) and you still needed a guest kernel that could handle the G5
due to different cache line size that affects at least dcbz which is used
to clear memory so unless that's correctly emulated by KVM it may clear
more bytes than intended and break.

https://forum.hyperion-entertainment.com/viewtopic.php?t=4736&start=1410

I thought this picture showed ppc64 kernel at host (not mac, neo amiga) and
qemu-system-ppc with non-obvious bitness?

So considering the above, what may work is if you run a 32 bit ppc kernel
(G4 version) on your G5 for the host not using it as 64 bit instead of
ppc64 kernel and try a guest kernel that detects G5 CPU and knows how to
handle the different cache line size.

Are you saying 32bit *Linux* ppc kvm as host can handle 64bit guest kernel ?

I am not ever sure firmware here can load 32bit ppc Linux .. I'll try of
course.


Or find and fix the emulation of

different instructions on ppc64 in Linux KVM when running 32 bit ppc code
on 64 but host. There supposed to be some support for that but maybe it's
broken or never finished.

But as I said I don't know this and don't have PPC hardware to try, nor
interest to do it so it's just my understanding and guess, which may be
wrong, but that's probably where you should start looking. Hopefully there
are others here with more knowledge about it or who want to look at it.
You should also look at how to enable KVM debug logs in Linux kernel and
see if you get any errors in the syslog. The usual QEMU debug options are
not that helpful with KVM and you should look for KVM logs instead.

In theory I subscribed to linux-ppc (kernel) list. May be I should cc them
? (added to cc)

I tried kvm-unit-tests but they apparently require qemu (to my surprise!)
and mostly focus on pseries / kvm HV (not surprisingly)?

Is there anything smaller to test kvm_pr specifically?

I even tried to d/l svn version of Mac on Linux but this one failed to
compile with gcc 15.

svn checkout svn://svn.code.sf.net/p/mac-on-linux/code/trunk
mac-on-linux-code

Regards,
BALATON Zoltan