SMP for Qemu-syetem-ppc64( WIP ).

[PowerPC74]

Just in case I attach files here, balaton1 and balaton2 should arrive at some time in main qemu tree, qemu-mac99-cpus-v2.patch should be applied with git apply (at least in my case). qemu tree is commit b69801dd6b1eb4d107f7c2f643adf0a4e3ec9124 and openbios tree from https://github.com/mcayland/openbios.

Note that you need -M mac99,via=pmu or may be via=adb-pmu otherwise patch will segfault with -smp 2.

./qemu-system-ppc -M  mac99,via=pmu -cpu g4 -smp 1 -m 256 -hda ~/QEMU/Mac-netbsd-2gb.qcow2  -bios  ~/K38_sdcard1/Documents/openbios-qemu-smp.elf -accel tcg,thread=multi

a bit like this, I guess (NetBSD sadly regressed recently on qemu-system-ppc, so i can't log in into my macppc VM )

qemu-system-ppc no longer boots NetBSD/macppc (#2741) · Issues · QEMU / QEMU · GitLab

Host environment Operating system: Debian OS/kernel version: Linux gumbo 6.1.0-28-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.1.119-1 (2024-11-22) x86_64 GNU/Linux...

gitlab.com

You might want qemu-system-ppc64, but for gdb debugging I needed 32-bit qemu, it seems.

GDB usage — QEMU documentation

qemu-project.gitlab.io

I used tips from that page, just running gdb in Debian ppc32 running in another qemu instance with networking (so target IP was 10.0.2.2 ) For Linux you can add cmd arg "-nosmp" via -append "args" qemu switch.

./qemu-system-ppc64 -M  mac99,via=pmu -cpu 7450 -smp 2 -m 512 -kernel
~/boot/vmlinux -nographic  -bios  ~/K38_sdcard1/Documents/openbios-qemu-smp.elf
-accel tcg,thread=multi -boot d -append "console=ttyPZ0"

I tried cpu g4 and cpu 7450 without any difference.

Kernel deb at

Браузер устарел / Облако Mail

cloud.mail.ru

MTCCG info at

Multi-threaded TCG — QEMU documentation

www.qemu.org

Balaton's patches for the GPIO appear to have made it to the master, so only the qemu-mac99-cpus-v2.patch is needed for testing now.

So if anyone wants to test, we really need tester, it's pretty easy to do now.

Install the needed dependancies with brew:

Building QEMU for macOS​

The system requirements are:

• One of the two most recent versions of macOS (currently Ventura or Sonoma)
• The clang compiler shipped with the version of Xcode for that OS X. GCC might also work, but we recommend clang

Additional build requirements are:

• libffi
• gettext
• glib
• pkg-config
• pixman
• ninja
• meson

As Qemu can now also run in SDL or GTK windows besides a Cocoa window, optionally you can install the SDL2 and./or gtk+3 devel packages.

make (when installed through brew, make is installed as gmake, so use gmake)

After downloading the QEMU source code, double-click it to expand it.

Then configure and make QEMU. The target-list option is used to build only the machine or machines you want. If you don't specify it, all machines would be built. Probably not what you want.

Pull the latest git repo of qemu:

git clone https://github.com/qemu/qemu.git

Then move the patch to the qemu directory and:

cd qemu
git apply mac99-cpus-v2.patch
mkdir build && cd build
../configure --target-list=ppc64-softmmu
mke -j8

If the build is successful, you should now have a qemu-system-ppc64 binary in the build directory, for testing you can run it from there:

./qemu-system-ppc64-unsigned \
-M mac99,via=pmu \
-m 1024 \
-hda <disk-img> \
-bios openbios-qemu-smp.elf  \
-cpu 7450 \
-cdrom <install-img>  \
-boot d \
-prom-env 'boot-args=-v' \
-smp 2,cores=1,threads=1,sockets=2 \
-accel tcg,thread=multi

Just adjust the <disk-img> and <install-img> with you paths to the image files.

Tested and working are OS X Tiger/Leopard/Snow Leopard, OS 9 will boot but freeze on access to the second CPU. Classic mode works fine under Tiger with SMP aware apps about to use the second CPU.

Questions, fire away!

 

[barracuda156]

Install the needed dependancies with brew:

This is evil LOL

 

[PowerPC74]

Well I was rather hoping PCI Passthrough on a Raspberry PI 5 with a PCI_E 'hat' device was going to be mostly painless, or at least as mostly painless as PCI Passthrough ever gets.

There are some serious issues with this, the firmware or the kernel does not expose PCI_E add on devices into any of the IOMMU groups, the reasons maybe:

The main reason is that the Raspberry Pi 5’s current PCIe implementation and firmware don’t set up separate IOMMU groups for PCIe HAT devices. In other words, the Broadcom SoC and its accompanying firmware are designed so that attached PCIe devices aren’t isolated into distinct IOMMU domains. This means:

• Hardware/Firmware Design: The SoC’s PCIe interface is set up with a single (or non-existent) IOMMU mapping for external devices rather than creating individual groups.
• Device Tree & Kernel Support: The configuration (via device tree and kernel drivers) hasn’t been updated or designed to enumerate each PCIe HAT in its own IOMMU group, which is necessary for finer-grained DMA isolation and virtualization.

As a result, even if you attach a PCIe HAT, you won’t see it segregated into its own IOMMU group. This is a limitation of the current design rather than a bug, and it may be revisited in future firmware or kernel updates if the need for finer device isolation arises.

This is as deep in the weeds as you get, there maybe an issue or issues with the fundamental design of the Pi 5 SoC that forever prevent PCI Passthrough, and even if that is not true the simplest fix will involve deep hardware understanding of the PI 5 and completely rewriting the IOMMU kernel driver for the BCM2712 devices if not also the PI 5's firmware too.

Not something I likely have time for, and this is a sad thing, because I was really looking forward to making a good writeup about a Dual G4 vs a RPI 5 to see if the PI 5 could compete running the Mac OS.

Without the ability to add PCI/E cards to the system, specifically Graphics Cards, it's just a non-starter, to me the Mac OS is nothing without accelerated graphics support. The Mac OS was about graphics from day one, back when it was called System 1.0. The whole idea of the Mac was the UGI and they just built on that over time.

When Jaguar shipped it the the fist GUI to run it's texture in VRAM and on the GPU, Linux and Windows fallowed what Apple did, as is normally the case.

Microsoft holds the greatest user base in the 3D gaming space, and for good reason with their DirectX interface monopoly, but they have never been able to match the macOS it how fluid the desktop is, they have always just looked at what Apple did and tried to match the appearance in failed ways.

There is always hope that somewhere upstream in the Linux Kernel someone is working on IOMMU for the PI 5 and they can address these issues, or the Pi 6 could. Or that Apple could enable PCI Passthrough on the macOS( finally ), but short of that the best we can really do is port the Voodoo2 emulation to qemu for the classic Mac OS, but that leaves OS X and 3D accelerated desktops out in the cold for now on aarch64 system that are priced cheap enough to make them a feasible replacement for our aging G4 systems when it comes to ruing PPC Mac OS.

I was really hoping to go out with one last great GFX hack for PowerPC, as if St Peter was going to have that on his list.

It was worth a shot and at least we laid a good ground work CPU wise enabling SMP for the Mac OS in Qemu-PPC.

Farewell folks, farewell.

 

[Andrew-R]

And i tried GENERIC.MP kernel on NetBSD/macpcc (whole qemu from git aborts later in userspace but I just wanted to see if kernel recognizes and can use second cpu)

it stopped at this function in kernel:

https://nxr.netbsd.org/xref/src/sys/arch/powerpc/oea/cpu_subr.c#1389

netbsd10$ ~/src/qemu/build/qemu-system-ppc64 -L /usr/pkg/share/qemu/ 
-hda ~/QEMU/Mac-netbsd-2gb.qcow2  -boot c 
-prom-env  'boot-device=hd:,ofwboot.xcf;1' -cpu G4 
-M mac99,via=pmu -display sdl  -netdev user,id=myslirp,ipv6=off 
-device e1000,        netdev=myslirp -m 256 -smp 2 
-bios ~/obj-ppc/openbios-qemu.elf -accel tcg,thread=multi 
-nographic -d guest_errors,unimp,int                                             
cpus[0] = 0x7caad347a040 0x7caad347cbc0                                                 
cpus[1] = 0x7caad319ea40 0x7caad31a15c0                                                 
Raise exception at 00000000fff08b50 => ISI (3) error=40000000                           
Raise exception at 00000000fff2d980 => ISI (3) error=40000000                           
Raise exception at 00000000fff2d980 => DSI (2) error=00                                 
Raise exception at 00000000fff2d984 => DSI (2) error=00                                 
Raise exception at 00000000fff025b4 => ISI (3) error=40000000                           
Raise exception at 00000000fff025bc => DSI (2) error=00                                 
Raise exception at 00000000fff025c0 => DSI (2) error=00                                 
Raise exception at 00000000fff08230 => DSI (2) error=00                                 
Raise exception at 00000000fff2c86c => ISI (3) error=40000000                           
Raise exception at 00000000fff2c880 => DSI (2) error=00                                 
Raise exception at 00000000fff2c880 => DSI (2) error=00                                 
Raise exception at 00000000fff097f0 => ISI (3) error=40000000                           
Raise exception at 00000000fff1ddb4 => ISI (3) error=40000000                           
Raise exception at 00000000fff1ddc4 => DSI (2) error=00                                 
Raise exception at 00000000fff1dbb4 => DSI (2) error=00                                 
Raise exception at 00000000fff2c70c => DSI (2) error=00                                 
Raise exception at 00000000fff09884 => DSI (2) error=00                                 
Raise exception at 00000000fff0e9a8 => ISI (3) error=40000000                           
Raise exception at 00000000fff107f4 => ISI (3) error=40000000                           
Raise exception at 00000000fff10824 => DSI (2) error=00                                 
Raise exception at s>> et_property: NULL phandle                                       

>> =============================================================                       
>> OpenBIOS 1.1 [Mar 12 2025 00:31]                                                     
>> Configuration device id QEMU version 1 machine id 1                                 
>> CPUs: 2                                                                             
>> Memory: 256M                                                                         
>> UUID: 00000000-0000-0000-0000-000000000000                                           
>> Pir = 0     
>> CPU type PowerPC,G4                                                                 
>> Pir = 0                                                                             
>> CPU type PowerPC,G4
milliseconds isn't unique.
Welcome to OpenBIOS v1.1 built on Mar 12 2025 00:31
Trying hd:,ofwboot.xcf;1...
>> switching to new context:

>> NetBSD/macppc OpenFirmware Boot, Revision 1.14 (Thu Mar 28 08:33:33 UTC 2024)
>> Open Firmware version 3.x
>> Open Firmware running in virtual-mode.
11835644+167308 [463968+447624]=0xc51508
 start=0x100000
[   1.0000000] Copyright (c) 1996, 1997, 1998, 1999, 2000, 2001, 2002, 2003,
[   1.0000000]     2004, 2005, 2006, 2007, 2008, 2009, 2010, 2011, 2012, 2013,
[   1.0000000]     2014, 2015, 2016, 2017, 2018, 2019, 2020, 2021, 2022, 2023,
[   1.0000000]     2024
[   1.0000000]     The NetBSD Foundation, Inc.  All rights reserved.
[   1.0000000] Copyright (c) 1982, 1986, 1989, 1991, 1993
[   1.0000000]     The Regents of the University of California.  All rights reserved.

[   1.0000000] NetBSD 10.0 (GENERIC.MP) #0: Thu Mar 28 08:33:33 UTC 2024
[   1.0000000]  mkrepro@mkrepro.NetBSD.org:/usr/src/sys/arch/macppc/compile/GENERIC.MP
[   1.0000000] total memory = 256 MB
[   1.0000000] avail memory = 225 MB
[   1.0000000] found openpic PIC at 80040000
[   1.0000000] OpenPIC Version 1.2: Supports 2 CPUs and 64 interrupt sources.
[   1.0000000] bootpath: /pci@f2000000/mac-io@c/ata-3@20000/disk@0:0/netbsd
[   1.0000000] mainbus0 (root)
[   1.0000000] cpu0 at mainbus0: 7400 (Revision 2.9), ID 0 (primary)
[   1.0000000] cpu0: HID0 0x809400a4<EMCP,DOZE,DPM,EIEC,SGE,BTIC,BHT>, powersave: 1
[   1.0000000] cpu0: 0.00 MHz L2 cache present but not enabled
[   1.0000000] cpu1 at mainbus00:CPU 1 didn't start 0
Stopped in pid 0.0 (system) at  netbsd:cpu_spinup+0x2cc:        lwz     r27, 0xf
c(r1)
db{0}> h
b               delete          match           search          w
break           dmesg           next            set             watch
bt              dwatch          p               show            whatis
c               examine         print           sifting         write
call            exit            ps              step            x
callout         help            quit            sync
continue        kill            reboot          trace
d               machine         s               until
db{0}> bt
0x00d55cd0: at config_attach_internal+0x254
0x00d55d00: at config_found+0x140
0x00d55d40: at mainbus_attach+0x290
0x00d55e40: at config_attach_internal+0x254
0x00d55e70: at config_rootfound+0x6c
0x00d55eb0: at cpu_configure+0x24
0x00d55ec0: at main+0x290
0x00d55f10: at 0x1000bc
db{0}> machine
bat     mmu     cpu
db{0}> thread 2
No such command: thread
db{0}> next
After 11 instructions (0 loads, 0 stores),
Stopped in pid 0.0 (system) at  netbsd:cpu_spinup+0x274:        blr
db{0}> next

Nothing interesting but I thought may be etBSD is easier than Linux when it comes to kernel features.

It does hang differently if I use -accel tcg.thread=single, somewhere around cd drive detection

Spoiler

>> NetBSD/macppc OpenFirmware Boot, Revision 1.14 (Thu Mar 28 08:33:33 UTC 2024)
>> Open Firmware version 3.x
>> Open Firmware running in virtual-mode.
11835644+167308 [463968+447624]=0xc51508
 start=0x100000
[   1.0000000] Copyright (c) 1996, 1997, 1998, 1999, 2000, 2001, 2002, 2003,
[   1.0000000]     2004, 2005, 2006, 2007, 2008, 2009, 2010, 2011, 2012, 2013,
[   1.0000000]     2014, 2015, 2016, 2017, 2018, 2019, 2020, 2021, 2022, 2023,
[   1.0000000]     2024
[   1.0000000]     The NetBSD Foundation, Inc.  All rights reserved.
[   1.0000000] Copyright (c) 1982, 1986, 1989, 1991, 1993
[   1.0000000]     The Regents of the University of California.  All rights reserved.

[   1.0000000] NetBSD 10.0 (GENERIC.MP) #0: Thu Mar 28 08:33:33 UTC 2024
[   1.0000000]  mkrepro@mkrepro.NetBSD.org:/usr/src/sys/arch/macppc/compile/GENERIC.MP
[   1.0000000] total memory = 256 MB
[   1.0000000] avail memory = 225 MB
[   1.0000000] found openpic PIC at 80040000
[   1.0000000] OpenPIC Version 1.2: Supports 2 CPUs and 64 interrupt sources.
[   1.0000000] bootpath: /pci@f2000000/mac-io@c/ata-3@20000/disk@0:0/netbsd
[   1.0000000] mainbus0 (root)
[   1.0000000] cpu0 at mainbus0: 7400 (Revision 2.9), ID 0 (primary)
[   1.0000000] cpu0: HID0 0x809400a4<EMCP,DOZE,DPM,EIEC,SGE,BTIC,BHT>, powersave: 1
[   1.0000000] cpu0: 0.00 MHz L2 cache present but not enabled 
[   1.0000000] cpu1 at mainbus0: 7400 (Revision 2.9), ID 1
[   1.0000000] cpu1: HID0 0x809400a4<EMCP,DOZE,DPM,EIEC,SGE,BTIC,BHT>, powersave: 1
[   1.0000000] cpu1: 0.00 MHz L2 cache present but not enabled 
[   1.0000000] memory0 at mainbus0
[   1.0000000] uninorth0 at mainbus0
[   1.0000000] pci0 at uninorth0 bus 0
[   1.0000000] pchb0 at pci0 dev 11 function 0
[   1.0000000] pchb0: Apple Computer UniNorth Host-PCI Bridge (rev. 0x00)
[   1.0000000] obio0 at pci0 dev 12 function 0: addr 0x80000000
[   1.0000000] obio0: enabling KeyLargo internal modem
[   1.0000000] pmu0 at obio0 offset 0x16000 irq 47:  rev. 1
[   1.0000000] pmu0: initializing RTC
[   1.0000000] pmu0: power-mgt not configured
[   1.0000000] zsc0 at obio0 irq 37,36
[   1.0000000] zstty0 at zsc0 channel 0 (console i/o)
[   1.0000000] zstty1 at zsc0 channel 1
[   1.0000000] wdc0 at obio0 offset 0x20000 irq 13, level triggered: DMA transfer
[   1.0000000] atabus0 at wdc0 channel 0
[   1.0000000] wdc1 at obio0 offset 0x21000 irq 14, level triggered: DMA transfer
[   1.0000000] atabus1 at wdc1 channel 0
[   1.0000000] ohci0 at pci0 dev 13 function 0: Apple Computer Intrepid USB Controller (rev. 0x00)
[   1.0000000] ohci0: interrupting at irq 28
[   1.0000000] ohci0: OHCI version 1.0
[   1.0000000] usb0 at ohci0: USB revision 1.0
[   1.0000000] genfb0 at pci0 dev 14 function 0: vendor 1234 product 1111 (rev. 0x02)
[   1.0000000] wm0 at pci0 dev 15 function 0: Intel i82540EM 1000BASE-T Ethernet (rev. 0x03)
[   1.0000000] wm0: interrupting at irq 30
[   1.0000000] wm0: Ethernet address 52:54:00:12:34:56
[   1.0000000] makphy0 at wm0 phy 1: Marvell 88E1011 Gigabit PHY, rev. 0
[   1.0000000] makphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-FDX, auto
[   1.0000000] uni_n0 at mainbus0 address 0xf8000000
[   1.0000000] vmmask 3f800000 schedmask 3f800000 highmask 7f800000
[   1.0042710] cpu1 started
[   1.0985928] WARNING: system needs entropy for security; see entropy(7)
[   1.1281237] uhub0 at usb0: NetBSD (0x0000) OHCI root hub (0x0000), class 9/0, rev 1.00/1.00, addr 1
[   3.0584944] uhidev0 at uhub0 port 1 configuration 1 interface 0
[   3.0584944] uhidev0: QEMU (0x0627) QEMU USB Keyboard (0x0001), rev 2.00/0.00, addr 2, iclass 3/1
[   3.1185554] ukbd0 at uhidev0: 8 Variable keys, 6 Array codes
[   3.1185554] wskbd0 at ukbd0 mux 1
[   4.4984718] uhidev1 at uhub0 port 2 configuration 1 interface 0
[   4.4984718] uhidev1: QEMU (0x0627) QEMU USB Mouse (0x0001), rev 2.00/0.00, addr 3, iclass 3/1
[   4.5584394] ums0 at uhidev1: 5 buttons and Z dir
[   4.5584394] wsmouse0 at ums0 mux 0
[   7.2283798] wd0 at atabus0 drive 0
[   7.2483519] wd0: <QEMU HARDDISK>
[   7.2483519] wd0: 2048 MB, 4161 cyl, 16 head, 63 sec, 512 bytes/sect x 4194304 sectors
[   7.2983701] atapibus0 at atabus1: 2 targets
[   7.3389024] cd0 at atapibus0 drive 0: <QEMU DVD-ROM, QM00003, 2.5+> cdrom removable

 

[PowerPC74]

The RPI seems to use a limited IOMMU controller circuit that is not full featured to support IOMMU isolation for PCI-E add on devices. Seems to be a hardware limitation to save money and complexity.

Not a design flaw per say, but a limitation of the design.

The IOMMU/DMA remapping is built into the Broadcom SoC on the PI and it just does not implement or even support isolated IOMMU groups for most devices, and none for external devices.

They designed it with a very specific limited feature set, so it's not a bug or something we can work around in the Linux Kernel or even the PI 5 firmware. The hardware lacks the needed features to support PCI Passthrough of a device connected to the M.2 Hat+ PCI-E bus.

Maybe they will address that in the PI 6 or later, we can hope.

 

[PowerPC74]

The RPI seems to use a limited IOMMU controller circuit that is not full featured to support IOMMU isolation for PCI-E add on devices. Seems to be a hardware limitation to save money and complexity.

Not a design flaw per say, but a limitation of the design.

The IOMMU/DMA remapping is built into the Broadcom SoC on the PI and it just does not implement or even support isolated IOMMU groups for most devices, and none for external devices.

They designed it with a very specific limited feature set, so it's not a bug or something we can work around in the Linux Kernel or even the PI 5 firmware. The hardware lacks the needed features to support PCI Passthrough of a device connected to the M.2 Hat+ PCI-E bus.

Maybe they will address that in the PI 6 or later, we can hope.

I just want to add to this that IOMMU and DMA remapping are security enhancements that limit vectors for attack. The reason Broadcom and other designers include IOMMU is not for PCI Passthough per say, it's to isolate devices memory regions so that out of bounds attacks on the security of the system as a whole are complex and limited.

The choice by Broadcom and Raspberry PI to include a limited IOMMU that doesn't support isolated IOMMU groups for the M.2 Hat+ PCI-E devices is a serious security vulnerability, especially if a network card, such as a Wifi card is used in that slot.

Sounds like a 'good' Blackhat demonstration to me!

 

[Andrew-R]

After some playing with -icount parameter of Qemu (incompatible with -accel tcg,thread=multi, but more determenistic) I found that this beauty of patch

diff --git a/hw/ppc/mac_newworld.c b/hw/ppc/mac_newworld.c
index 51f316e513..028fa62263 100644
--- a/hw/ppc/mac_newworld.c
+++ b/hw/ppc/mac_newworld.c
@@ -134,6 +134,7 @@ static void cpu_kick(void *opaque, int n, int level)
     PowerPCCPU *cpu = opaque;
     CPUState *cs = CPU(cpu);
 
+    sleep(1);
     if (level) {
         cpu->env.excp_prefix = 0;
         cpu_reset(cs);

EDIT:
might be slightly better esp for Windows

diff --git a/hw/ppc/mac_newworld.c b/hw/ppc/mac_newworld.c
index 51f316e513..78ba9a61da 100644
--- a/hw/ppc/mac_newworld.c
+++ b/hw/ppc/mac_newworld.c
@@ -134,6 +134,7 @@ static void cpu_kick(void *opaque, int n, int level)
     PowerPCCPU *cpu = opaque;
     CPUState *cs = CPU(cpu);
 
+    nanosleep((const struct timespec[]){{0, 500000000L}}, NULL);
     if (level) {
         cpu->env.excp_prefix = 0;
         cpu_reset(cs);

Does fix my Gentoo 2007/8 install cds and Debian ppc32 Sid/Trixie

And Leopard (10.5) still boots with two cpus!

BSDs (FreeBSD 14.2 and NetBSD 10.1) still have trouble with second cpu activated

 

[Andrew-R]

Do you know btw why it cannot emulate G5?

I tried to look into this question.

Linux (Gentoo 2008) can see one 970FX processor, but Leopard (10.5) kinda unhappy:

Tried to boot Leopard (10.5) on qemu's 970FX

I tried to add last two hypervisor SPRs but this did not make it boot. I am afraid it might require more than this (see thread for Serial Communication Facility on 970FX/MP - as far as I can see it not implemented in qemu)

 

[PowerPC74]

After some playing with -icount parameter of Qemu (incompatible with -accel tcg,thread=multi, but more determenistic) I found that this beauty of patch

diff --git a/hw/ppc/mac_newworld.c b/hw/ppc/mac_newworld.c
index 51f316e513..028fa62263 100644
--- a/hw/ppc/mac_newworld.c
+++ b/hw/ppc/mac_newworld.c
@@ -134,6 +134,7 @@ static void cpu_kick(void *opaque, int n, int level)
     PowerPCCPU *cpu = opaque;
     CPUState *cs = CPU(cpu);
 
+    sleep(1);
     if (level) {
         cpu->env.excp_prefix = 0;
         cpu_reset(cs);

EDIT:
might be slightly better esp for Windows

diff --git a/hw/ppc/mac_newworld.c b/hw/ppc/mac_newworld.c
index 51f316e513..78ba9a61da 100644
--- a/hw/ppc/mac_newworld.c
+++ b/hw/ppc/mac_newworld.c
@@ -134,6 +134,7 @@ static void cpu_kick(void *opaque, int n, int level)
     PowerPCCPU *cpu = opaque;
     CPUState *cs = CPU(cpu);
 
+    nanosleep((const struct timespec[]){{0, 500000000L}}, NULL);
     if (level) {
         cpu->env.excp_prefix = 0;
         cpu_reset(cs);

Does fix my Gentoo 2007/8 install cds and Debian ppc32 Sid/Trixie

And Leopard (10.5) still boots with two cpus!

BSDs (FreeBSD 14.2 and NetBSD 10.1) still have trouble with second cpu activated

I wonder if the delay you are setting is just a hack for not reseting the timebase?

 

[Andrew-R]

I wonder if the delay you are setting is just a hack for not reseting the timebase?

Mm .. I do not know, honestly. I looked around qemu sources and there is comment saying all vCPUs started with pre-synchronized timebase.

In Linux/NetBSD sources there is delay (mdelay() in Linux, just loop in NetBSD) before second processor poked again..

So, *I think* on real hardware second CPU starts with some small delay, too. But this of course still leaves question why MacOSX not affected.

I also wonder if anyone having Linux/kvm setup on those G5s ... But there was special thread about that, will look for it.

You surely can play with progressively smaller value of delay until Linux no longer boots with both processors

 

[PowerPC74]

Mm .. I do not know, honestly. I looked around qemu sources and there is comment saying all vCPUs started with pre-synchronized timebase.

In Linux/NetBSD sources there is delay (mdelay() in Linux, just loop in NetBSD) before second processor poked again..

So, *I think* on real hardware second CPU starts with some small delay, too. But this of course still leaves question why MacOSX not affected.

I also wonder if anyone having Linux/kvm setup on those G5s ... But there was special thread about that, will look for it.

You surely can play with progressively smaller value of delay until Linux no longer boots with both processors

I don't know what the deal is with OS 9, the delay did not help things there, but implementing a few of the OF properties from the second CPU in Openbios gets things a little further before the mouse freeze. The clock stops the the GUI doesn't seem to fully update in real time when running SMP aware apps once they touch the second CPU, but it does seem to operate and execute code.

CineBench 2000 gets quite a bit further running the Benchmark, but the RTC or System Clock freeze that comes with the mouse freeze skews the results.

QT encoding of MPEG2 which uses the 2nd CPU also freezes the mouse/clock, but it does finish encoding the MPEG2 file and writes it to disk. The speedup from the 2nd CPU is about what we would expect, so the 2nd CPU is working, we just need to figure out why using it freezes the mouse/clock/RTC????

 

[Andrew-R]

I don't know what the deal is with OS 9, the delay did not help things there, but implementing a few of the OF properties from the second CPU in Openbios gets things a little further before the mouse freeze. The clock stops the the GUI doesn't seem to fully update in real time when running SMP aware apps once they touch the second CPU, but it does seem to operate and execute code.

CineBench 2000 gets quite a bit further running the Benchmark, but the RTC or System Clock freeze that comes with the mouse freeze skews the results.

QT encoding of MPEG2 which uses the 2nd CPU also freezes the mouse/clock, but it does finish encoding the MPEG2 file and writes it to disk. The speedup from the 2nd CPU is about what we would expect, so the 2nd CPU is working, we just need to figure out why using it freezes the mouse/clock/RTC????

Yeah, 9.2 is more "black box" compared to X. Thanks for experimenting on it .... I only crashed my 9.2 install by trying usb-audio on it. There was no new guest_errors in qemu's log so I am not sure why it behaved like this.

For SMP task I tried to just open Quicktime 6.0.3's sample video, double side it, and then save as svq3 (not multithreaded by itself in basic version), but added few filters (old film + black and white). From my observation whole process was using more than 100% of host cpu, and finished without freezing mouse. May be built-in audio components of OS 9.2.2 interfere somewhat? I noticed with 9.2 I see few errors not present with OSX:

netbsd10$ ~/src/qemu/build/qemu-system-ppc64 -bios ~/obj-ppc/openbios-qemu.elf
-M mac99,via=pmu  -hda ~/AndrewR/disk.qcow2        -L /usr/pkg/share/qemu/  -d
guest_errors,unimp -accel tcg,thread=multi -cpu g4  -smp 2  -display sdl   -boot c -m 1024 -device usb-audio
cpus[0] = 0x7dab08461040 0x7dab08463bc0
cpus[1] = 0x7dab08155c00 0x7dab08158780
Trying to write invalid spr 0 (0x000) at 0000000000f113c0
Trying to read invalid spr 0 (0x000) at 0000000000f113c8
Trying to write privileged spr 955 (0x3bb) at 0000000000f168c8
Trying to write invalid spr 959 (0x3bf) at 0000000000f16930
Trying to read invalid spr 959 (0x3bf) at 0000000000f16938
Trying to write privileged spr 955 (0x3bb) at 0000000000f168c8
Trying to write invalid spr 959 (0x3bf) at 0000000000f16930
Trying to read invalid spr 959 (0x3bf) at 0000000000f16938
portA_write unimplemented
portA_write unimplemented
PMU: Unsupported READ_PMU_RAM, args: 80 02 03
PMU: Unsupported READ_PMU_RAM, args: 80 02 03
sungem: WOL not supported
sungem: WOL not supported
sungem: WOL not supported
sungem: WOL not supported
dbdma_unassigned_flush: use of unassigned channel 12
dbdma_unassigned_flush: use of unassigned channel 12
dbdma_unassigned_flush: use of unassigned channel 14
dbdma_unassigned_rw: use of unassigned channel 14
dbdma_unassigned_flush: use of unassigned channel 14

This is non-sceamer build, so i am not sure what exactly OS 9.2.2 tries to do here ... They exist even without -device usb-audio

 

[PowerPC74]

Yeah, 9.2 is more "black box" compared to X. Thanks for experimenting on it .... I only crashed my 9.2 install by trying usb-audio on it. There was no new guest_errors in qemu's log so I am not sure why it behaved like this.

For SMP task I tried to just open Quicktime 6.0.3's sample video, double side it, and then save as svq3 (not multithreaded by itself in basic version), but added few filters (old film + black and white). From my observation whole process was using more than 100% of host cpu, and finished without freezing mouse. May be built-in audio components of OS 9.2.2 interfere somewhat? I noticed with 9.2 I see few errors not present with OSX:

netbsd10$ ~/src/qemu/build/qemu-system-ppc64 -bios ~/obj-ppc/openbios-qemu.elf
-M mac99,via=pmu  -hda ~/AndrewR/disk.qcow2        -L /usr/pkg/share/qemu/  -d
guest_errors,unimp -accel tcg,thread=multi -cpu g4  -smp 2  -display sdl   -boot c -m 1024 -device usb-audio
cpus[0] = 0x7dab08461040 0x7dab08463bc0
cpus[1] = 0x7dab08155c00 0x7dab08158780
Trying to write invalid spr 0 (0x000) at 0000000000f113c0
Trying to read invalid spr 0 (0x000) at 0000000000f113c8
Trying to write privileged spr 955 (0x3bb) at 0000000000f168c8
Trying to write invalid spr 959 (0x3bf) at 0000000000f16930
Trying to read invalid spr 959 (0x3bf) at 0000000000f16938
Trying to write privileged spr 955 (0x3bb) at 0000000000f168c8
Trying to write invalid spr 959 (0x3bf) at 0000000000f16930
Trying to read invalid spr 959 (0x3bf) at 0000000000f16938
portA_write unimplemented
portA_write unimplemented
PMU: Unsupported READ_PMU_RAM, args: 80 02 03
PMU: Unsupported READ_PMU_RAM, args: 80 02 03
sungem: WOL not supported
sungem: WOL not supported
sungem: WOL not supported
sungem: WOL not supported
dbdma_unassigned_flush: use of unassigned channel 12
dbdma_unassigned_flush: use of unassigned channel 12
dbdma_unassigned_flush: use of unassigned channel 14
dbdma_unassigned_rw: use of unassigned channel 14
dbdma_unassigned_flush: use of unassigned channel 14

This is non-sceamer build, so i am not sure what exactly OS 9.2.2 tries to do here ... They exist even without -device usb-audio

Did you try and trace "mac-io*" to see if it logs anything for the GPIO when it hangs?

I can't seem to get the syntax correct to trace mac-io anymore, worked fine before in the qemu.log but now I just get an empty log file.

 

[Andrew-R]

Did you try and trace "mac-io*" to see if it logs anything for the GPIO when it hangs?

I can't seem to get the syntax correct to trace mac-io anymore, worked fine before in the qemu.log but now I just get an empty log file.

try -d trace:*macio* at the end of your usual command line ..?

so far screamer under 9.2/Quicktime6 plays test mp3, but uner 10.4.11 it heavily distorted. Both run with -M mac99,via=pmu, OSX even with smp 2. Will try with via=pmu-adb

 

[Andrew-R]

So, I added Screamer patches on top of smp patch (+delay patch), and reverted commit breaking netBSD so I can test netBSD/macppc audio output, too. Hypervisor SPR hacks probably not needed but included anyway.

Openbios also patched with both my series and Mark's Screamer patch.

Attach contain qemu patcehs, openbios patches, and openbios binary.

 

[PowerPC74]

I managed to get 4 emulated G4 CPUs working under Mac OS X Tiger( 10.4.11 ).

Sadly I can't do much with it because somehow my patches break keyboard and mouse IO.

I was able to put apps in the login items and they run, so the system is not frozen.

Altivec Fractional Carbon runs 4x as fast as single CPU and 2x as fast as dual CPU, topping out at 417% CPU usage in Activity Monitor in the Tiger Guest.

I also got it somewhat working with Mac OS 9.

The Max CPUs for OS 9 is 4, anything more and it reverts to single CPU. Also the Max CPUs that OS X Tiger tries to 'kick-start' is 4.


I was hoping OS X did not have a 4 CPU limit, but it doesn't seem to try and 'soft-reset' more than 4. I'll have to do some code changes to see if I can add code for the GPIO for more than 4 CPUs and if OS X will try and kick them.

 

[Andrew-R]

May be 4 is openpic (interrupt controller) limit ? I think new G5 openpic was up to 8 cpus in theory, but may be guest os kernel must be modified to even try?

EDIT:

linux-xlnx/arch/powerpc/include/asm/keylargo.h at master · Xilinx/linux-xlnx

The official Linux kernel from Xilinx. Contribute to Xilinx/linux-xlnx development by creating an account on GitHub.

github.com

Linux sources list 4 cpu_reset lines but only assert/release for cpu1 ?

 

[Andrew-R]

I managed to get 4 emulated G4 CPUs working under Mac OS X Tiger( 10.4.11 ).

Sadly I can't do much with it because somehow my patches break keyboard and mouse IO.

I was able to put apps in the login items and they run, so the system is not frozen.

Altivec Fractional Carbon runs 4x as fast as single CPU and 2x as fast as dual CPU, topping out at 417% CPU usage in Activity Monitor in the Tiger Guest.

I also got it somewhat working with Mac OS 9.

The Max CPUs for OS 9 is 4, anything more and it reverts to single CPU. Also the Max CPUs that OS X Tiger tries to 'kick-start' is 4.


I was hoping OS X did not have a 4 CPU limit, but it doesn't seem to try and 'soft-reset' more than 4. I'll have to do some code changes to see if I can add code for the GPIO for more than 4 CPUs and if OS X will try and kick them.

wow, it works

 

[Andrew-R]

qemu-only patches, I saw new info reposted to qemu list, but not incorporated yet. should be applicable on top of qemu 10.0-rc0

Re: mac99 SMP

my reply to list was

=====
Anyway, I tried 9.2.2 and not sure if Final Cut Pro 2.x (yeah, prehistoric) was able to do any smp with 4 cpu, yet it was going slightly above 100% (host) on -smp 2.


Leopard (10.5, not updated) was hanging with stop symbol on -smp 4 but worked on -smp 2

Void Linux (ppc32, 5.13 and 4. something kernels) was finding all four cpus, same for modern Debian on vmlinux-6.12.16-powerpc-smp . Sound was unhappy on this kernel, but worked at least for terminal bell on Void installer. Interestingly Debian kernel does spread device interrupts (as seen in /proc/interrupts) over all cpu cores.

BSDs (NetBSD 10.0 and FreeBSD 14.2) were still only working with -smp 1.

64 bit Debian was only able to use
one cpu (970FX), others were stuck. FreeBSD powerpc64 was no boot for me, 10.4.11/10.5 OSX still no boot on qemu-emulated 970 (FX or just 970).
=====

 

[PowerPC74]

Of course the lingering question is why does Mac OS X Tiger and Linux kick 4 G4 CPUs?

Was there in fact a Quad G4 Mac that was released to say the Steve Jobs owned Pixar?

That may explain why Cinema 4D supports 4 G4 CPUs…...

 

[PowerPC74]

Quad G3's and Quad 604e's work too!

 

[PowerPC74]

Why not a little Tiger action with the Quad 604e's( Thanks to @LightBulbFun for his 'no-halt' Tiger Kernel'

If someone wants to dig through OS X's xnu-kernel source code can can find where the extra CPU's are are started( 'kicked' ) I'm pretty sure we have just enough unused GPIO pins to get 8 CPU's working.

We'll need to find where the CPU are kicked in xnu- anyway if we want more than 2 cores working in Leopard/Snow Leopard DP PPC, as they only kick 2.

 

[PowerPC74]

Just to confirm I dug into the XNU sources for Mac OS X Tiger and it supports up to 256 CPUs on the PPC side of the code tree, I just have to find where it only kicks in 4 CPUs for core99( G4 Based PowerMacs ) and change the code to kick more CPUs.

Do we have any kernel hackers about?

#define MAX_CPUS 256

 

[PowerPC74]

Just to confirm I dug into the XNU sources for Mac OS X Tiger and it supports up to 256 CPUs on the PPC side of the code tree, I just have to find where it only kicks in 4 CPUs for core99( G4 Based PowerMacs ) and change the code to kick more CPUs.

Do we have any kernel hackers about?

#define MAX_CPUS 256

All the xnu sources for 10.4.11 point to MAX_CPUS 256 even the 'boot-args cpus=xxx' but it only works up to 4 CPUs. Nowhere in the code or the Platform Expert code for RICS2PE does it set a max cpus at anything other than 256. Yet Tiger will only kickstart 4 max and Leopard/Snow Leopard only kickstart 2, tho I have't look at those sources yet.

 

[LightBulbFun]

All the xnu sources for 10.4.11 point to MAX_CPUS 256 even the 'boot-args cpus=xxx' but it only works up to 4 CPUs. Nowhere in the code or the Platform Expert code for RICS2PE does it set a max cpus at anything other than 256. Yet Tiger will only kickstart 4 max and Leopard/Snow Leopard only kickstart 2, tho I have't look at those sources yet.

just as an FYI for PowerMac3,1 Tiger will use the Core99PE

RISC2PE is only used on later macs in tiger, and only used on the PowerMac3,1 machine by Leopard (it is why early Uninorth PowerMacs will kernel panic in Leopard, if the BootROM is not sufficiently up to date, since early BootROM versions do not report the MacRISC2 compatible property in the root of the device tree, so Leopard panics as it cant find a Platform Expert to use, as it only has the MacRISC2PE)