[PATCH] Add experimental SMP support for mac99/G4

[Andrew Randrianasulu]

Surely something still wrong because it breaks  -M g3beige :(

but at least

./qemu-system-ppc64 -accel tcg,thread=multi -smp 2 -M mac99,via=pmu
-cpu g4 -bios ~/obj-ppc/openbios-qemu.elf -display sdl -hda
~/QEMU/osx-tiger_10.4.11_installed-compressed.qcow

starts fine and uses two processors with corresponding qemu patch

Originally developed/posted at

https://mail.gnu.org/archive/html/qemu-ppc/2025-03/msg00020.html

[Andrew Randrianasulu]

On Wed, Mar 12, 2025 at 2:21 AM Andrew Randrianasulu
 wrote:
> Surely something still wrong because it breaks  -M g3beige :(

ah, as comrade Balaton noted I just ended up with finish-device twice
for !G4 case ..

Now fixed and hopefully second fix for 74XX cpus how is also useful ...
> but at least
>
> ./qemu-system-ppc64 -accel tcg,thread=multi -smp 2 -M mac99,via=pmu
> -cpu g4 -bios ~/obj-ppc/openbios-qemu.elf -display sdl -hda
> ~/QEMU/osx-tiger_10.4.11_installed-compressed.qcow
>
> starts fine and uses two processors with corresponding qemu patch
>
> Originally developed/posted at
>
> https://mail.gnu.org/archive/html/qemu-ppc/2025-03/msg00020.html

[BALATON Zoltan]

On Wed, 12 Mar 2025, Andrew Randrianasulu wrote:
> On Wed, Mar 12, 2025 at 2:21 AM Andrew Randrianasulu
>  wrote:
> > Surely something still wrong because it breaks  -M g3beige :(
>
> ah, as comrade Balaton noted I just ended up with finish-device twice
> for !G4 case ..
>
> Now fixed and hopefully second fix for 74XX cpus how is also useful ...

This isn't the right fix and not what I suggested. Instead of commenting 
out the other finish-devices you should also revert the one in g4_init and 
instead move the property settings in cpu_add_pir_property where you 
should have the CPU number already after fixing PIR setting in QEMU so you 
don't need to comment out anything and only add a loop around creating 
CPUs and the extra properties for G4. That way it should not break other 
CPU types.

(I don't think we're still comrades, at least since 1989 and even before 
we were'nt that much into that :-) )

Regards,
BALATON Zoltan
> > but at least
> >
> > ./qemu-system-ppc64 -accel tcg,thread=multi -smp 2 -M mac99,via=pmu
> > -cpu g4 -bios ~/obj-ppc/openbios-qemu.elf -display sdl -hda
> > ~/QEMU/osx-tiger_10.4.11_installed-compressed.qcow
> >
> > starts fine and uses two processors with corresponding qemu patch
> >
> > Originally developed/posted at
> >
> > https://mail.gnu.org/archive/html/qemu-ppc/2025-03/msg00020.html

[Andrew Randrianasulu]

On Wed, Mar 12, 2025 at 4:32 PM BALATON Zoltan  wrote:
> On Wed, 12 Mar 2025, Andrew Randrianasulu wrote:
> > On Wed, Mar 12, 2025 at 2:21 AM Andrew Randrianasulu
> >  wrote:
> > > Surely something still wrong because it breaks  -M g3beige :(
> >
> > ah, as comrade Balaton noted I just ended up with finish-device twice
> > for !G4 case ..
> >
> > Now fixed and hopefully second fix for 74XX cpus how is also useful ...
>
> This isn't the right fix and not what I suggested. Instead of commenting
> out the other finish-devices you should also revert the one in g4_init and
> instead move the property settings in cpu_add_pir_property where you
> should have the CPU number already after fixing PIR setting in QEMU

I still can't figure how to fix it there ....

also, with this "incorrect" way of finishing devices I booted Gentoo
2008/G5 with -smp 2/-cpu 970FX
and it reported use of software timebase syncronization, but still
second cpu was stuck

so at least it was useful for experiments

so you
> don't need to comment out anything and only add a loop around creating
> CPUs and the extra properties for G4. That way it should not break other
> CPU types.
>
> (I don't think we're still comrades, at least since 1989 and even before
> we were'nt that much into that :-) )
>
> Regards,
> BALATON Zoltan
> > > but at least
> > >
> > > ./qemu-system-ppc64 -accel tcg,thread=multi -smp 2 -M mac99,via=pmu
> > > -cpu g4 -bios ~/obj-ppc/openbios-qemu.elf -display sdl -hda
> > > ~/QEMU/osx-tiger_10.4.11_installed-compressed.qcow
> > >
> > > starts fine and uses two processors with corresponding qemu patch
> > >
> > > Originally developed/posted at
> > >
> > > https://mail.gnu.org/archive/html/qemu-ppc/2025-03/msg00020.html

[BALATON Zoltan]

On Wed, 12 Mar 2025, Andrew Randrianasulu wrote:
> On Wed, Mar 12, 2025 at 4:32 PM BALATON Zoltan  wrote:
> > On Wed, 12 Mar 2025, Andrew Randrianasulu wrote:
> > > On Wed, Mar 12, 2025 at 2:21 AM Andrew Randrianasulu
> > >  wrote:
> > > > Surely something still wrong because it breaks  -M g3beige :(
> > >
> > > ah, as comrade Balaton noted I just ended up with finish-device twice
> > > for !G4 case ..
> > >
> > > Now fixed and hopefully second fix for 74XX cpus how is also useful ...
> >
> > This isn't the right fix and not what I suggested. Instead of commenting
> > out the other finish-devices you should also revert the one in g4_init and
> > instead move the property settings in cpu_add_pir_property where you
> > should have the CPU number already after fixing PIR setting in QEMU
>
> I still can't figure how to fix it there ....

You have to fix PIR in QEMU first for that to work.
> also, with this "incorrect" way of finishing devices I booted Gentoo
> 2008/G5 with -smp 2/-cpu 970FX
> and it reported use of software timebase syncronization, but still
> second cpu was stuck
>
> so at least it was useful for experiments

OK but that probably does not differ from what we had before with the 
previous patch so maybe not much change from that.

Regards,
BALATON Zoltan

[Andrew Randrianasulu]

On Wed, Mar 12, 2025 at 4:49 PM BALATON Zoltan  wrote:
> On Wed, 12 Mar 2025, Andrew Randrianasulu wrote:
> > On Wed, Mar 12, 2025 at 4:32 PM BALATON Zoltan  wrote:
> > > On Wed, 12 Mar 2025, Andrew Randrianasulu wrote:
> > > > On Wed, Mar 12, 2025 at 2:21 AM Andrew Randrianasulu
> > > >  wrote:
> > > > > Surely something still wrong because it breaks  -M g3beige :(
> > > >
> > > > ah, as comrade Balaton noted I just ended up with finish-device twice
> > > > for !G4 case ..
> > > >
> > > > Now fixed and hopefully second fix for 74XX cpus how is also useful ...
> > >
> > > This isn't the right fix and not what I suggested. Instead of commenting
> > > out the other finish-devices you should also revert the one in g4_init and
> > > instead move the property settings in cpu_add_pir_property where you
> > > should have the CPU number already after fixing PIR setting in QEMU
> >
> > I still can't figure how to fix it there ....
>
> You have to fix PIR in QEMU first for that to work.
> > also, with this "incorrect" way of finishing devices I booted Gentoo
> > 2008/G5 with -smp 2/-cpu 970FX
> > and it reported use of software timebase syncronization, but still
> > second cpu was stuck
> >
> > so at least it was useful for experiments
>
> OK but that probably does not differ from what we had before with the
> previous patch so maybe not much change from that.

with previous (monolithic) patch it was impossible to start -cpu 970
-M mac99 at all, just like with g3beige ...

for same reason ...

I agree adding blindly properties to Device Tree not related to G4/SMP
where they were discovered is not good idea
Just all this Forth stack overflows me :/
> Regards,
> BALATON Zoltan