Re: mac99 SMP

[Andrew Randrianasulu]

On Sat, Mar 15, 2025 at 8:37 PM Andrew Randrianasulu
<randrianasulu@gmail.com> wrote:
>
>
>
> сб, 15 мар. 2025 г., 19:47 Andrew Randrianasulu <randrianasulu@gmail.com>:
>>
>> On Sat, Mar 15, 2025 at 7:07 PM BALATON Zoltan <balaton@eik.bme.hu> wrote:
>> >
>> > On Sat, 15 Mar 2025, Andrew Randrianasulu wrote:
>> > > On Sat, Mar 15, 2025 at 6:11 PM Andrew Randrianasulu
>> > > <randrianasulu@gmail.com> wrote:
>> > >> On Tue, Mar 11, 2025 at 12:18 AM Andrew Randrianasulu
>> > >> <randrianasulu@gmail.com> wrote:
>> > >>> On Mon, Mar 10, 2025 at 11:37 PM BALATON Zoltan <balaton@eik.bme.hu> 
>> > >>> wrote:
>> > >>>> On Mon, 10 Mar 2025, Andrew Randrianasulu wrote:
>> > >>>>> вс, 9 мар. 2025 г., 15:36 BALATON Zoltan <balaton@eik.bme.hu>:
>> > >>>>>> On Sun, 9 Mar 2025, Howard Spoelstra wrote:
>> > >>>>>>> On Sun, Mar 9, 2025 at 12:38 PM Andrew Randrianasulu <
>> > >>>>>> randrianasulu@gmail.com> wrote:
>> > >>>>>>>>>> I also noticed that  default gtk3 display tend to "freeze" 
>> > >>>>>>>>>> mouse in
>> > >>>>>> SMP OS
>> > >>>>>>>>>> 9.2.2 guest, but -display sdl worked fine so far. Set up host 
>> > >>>>>>>>>> ftp
>> > >>>>>> server
>> > >>>>>>>>>> for file transfers.
>> > >>>>>>>>>
>> > >>>>>>>>> Maybe Howard would be interested in that. But I think his builds 
>> > >>>>>>>>> also
>> > >>>>>> use
>> > >>>>>>>>> SDL, but seen this problem on Windows and macOS not Linux.BALATON
>> > >>>>>> Zoltan
>> > >>>>>>>>
>> > >>>>>>>>
>> > >>>>>>> On Windows host: with smp SDL also freezes after some time: we 
>> > >>>>>>> loose
>> > >>>>>> either
>> > >>>>>>> mouse clicks or movement.
>> > >>>>>>> The via=pmu defaults to using usb kbd/mouse. via=pmu-adb provides 
>> > >>>>>>> the pmu
>> > >>>>>>> but with adb kdb/mouse. That doesn't seem to crash.
>> > >>>>>>> To make things more complicated: OSX 10.0 and 10.1 will have no 
>> > >>>>>>> mouse
>> > >>>>>> when
>> > >>>>>>> running with via=pmu. This seems due to some USB problem, so even 
>> > >>>>>>> when
>> > >>>>>> the
>> > >>>>>>
>> > >>>>>> We have debugged this USB problem a few years ago and I think the 
>> > >>>>>> problem
>> > >>>>>> was that those early OSX versions try to detect devices by powering 
>> > >>>>>> the
>> > >>>>>> ports down and up and expect connected events from connected 
>> > >>>>>> devices but
>> > >>>>>> QEMU does not emulate port power management so these connect events 
>> > >>>>>> won't
>> > >>>>>> be generated. It could be fixed but I haven't written a patch and 
>> > >>>>>> hoped
>> > >>>>>> somebody else would do that but it seems nobody did so far. It 
>> > >>>>>> shouldn't
>> > >>>>>> be too hard, just need to get acquainted with the code in
>> > >>>>>> qemu/hw/usb/hcd-ohci.c, read the OHCI docs and implement the bits 
>> > >>>>>> that
>> > >>>>>> power down the port and generate connect events when the port is 
>> > >>>>>> powered
>> > >>>>>> up. Somebody who's interested to fix this could do that. This info 
>> > >>>>>> was on
>> > >>>>>> the list back when we debugged it too so already known for a few 
>> > >>>>>> years.
>> > >>>>>>
>> > >>>>>
>> > >>>>>
>> > >>>>> Do you think it should be put in official qemu bugtracker, if not 
>> > >>>>> already?
>> > >>>>> I mean usb power up/down for OHCI ?
>> > >>>>>
>> > >>>>> Should screamer patch get its tracking bug too?
>> > >>>>
>> > >>>> I don't know if anybody cares about the QEMU bugtracker for these
>> > >>>> machines. The maintainer is Mark and he's aware of the problems just
>> > >>>> doesn't have time to do much about them. Not sure having a bug would
>> > >>>> change that. (Maybe he forgot about this USB issue but now reminded 
>> > >>>> :-) )
>> > >>>>
>> > >>>>> Any other bugs/incomplete features?
>> > >>>>
>> > >>>> Probably a lot of them, some may already have tickets but who will fix
>> > >>>> them?
>> > >>>>
>> > >>>>> Semirelated - does g3 machine works for you right now? I think I got
>> > >>>>> blackscreen but may be it was  just messed up by me ....
>> > >>>>
>> > >>>> Haven't tried for a while but maybe the patched openbios does not work
>> > >>>> with it in case you replaced that in pc-bios?
>> > >>>
>> > >>> Yeah, seems to be just
>> > >>>  ./qemu-system-ppc -M g3beige works
>> > >>>
>> > >>> and
>> > >>>
>> > >>> ./qemu-system-ppc -M g3beige -bios 
>> > >>> ~/K38_sdcard1/Documents/openbios-qemu-smp.elf
>> > >>>
>> > >>> not ....
>> > >>>
>> > >>
>> > >>
>> > >> Interesting news!
>> > >>
>> > >> I tried -icount mode and  now qemu seems to bring up secondary cpu in 
>> > >> linux!
>> > >>
>> > >> But -icount incompatible with -accel tcg,thread=multi
>> > >>
>> > >> [    0.348805]  channel 2 bus <multibus>
>> > >> [    0.349086] Processor timebase sync using GPIO 0x73
>> > >> [    0.349253] mpic: requesting IPIs...
>> > >> [    0.350149] CPU0: L2CR is 0
>> > >> [    0.368310] rcu: Hierarchical SRCU implementation.
>> > >> [    0.368445] rcu:     Max phase no-delay instances is 1000.
>> > >> [    0.371401] Timer migration: 1 hierarchy levels; 8 children per
>> > >> group; 1 crossnode level
>> > >> [    0.388645] smp: Bringing up secondary CPUs ...
>> > >> smp_core99_kick_cpu
>> > >> [    0.398119] PowerMac call feature: 1
>> > >> smp_core99_kick_cpu done
>> > >> [    0.399977] PowerMac init caches!
>> > >> [    0.399977]
>> > >> [    0.400017] CPU1: L2CR was 0
>> > >> [    0.400099] CPU1: L2CR set to 0
>> > >> [    0.457990] smp: Brought up 1 node, 2 CPUs
>> > >>
>> > >>  ~/src/qemu/build/qemu-system-ppc64 -bios ~/obj-ppc/openbios-qemu.elf
>> > >> -M mac99,via=pmu  -kernel ~/boot/vmlinux  -L /usr/pkg/share/qemu/  -d
>> > >> guest_errors,unimp -nographic -icount shift=4,align=off,sleep=off -cpu
>> > >> g4 -append "console=ttyPZ0" -smp 2
>> > >>
>> > >> but in this version I also increased mdelay to 10 from 1 in original 
>> > >> code
>> > >>
>> > >> https://elixir.bootlin.com/linux/v6.12.17/source/arch/powerpc/platforms/powermac/smp.c#L827
>> > >>
>> > >> it does not work without -icount or with unmodded kernel
>> > >
>> > >
>> > > Oh, it does work with unmodified kernel and -icount=6
>> >
>> > I don't know what exactly -icount=6 does but according to
>> > https://www.qemu.org/docs/master/devel/multi-thread-tcg.html one thing
>> > that -icound does is disable -accel tcg,thread=multi so is -icount still
>> > needed if you don't enable MTTCG? Icount may also limit the translated
>> > code size so maybe we'd need to flush some TBs when starting a secondary
>> > CPU?
>>
>>
>> Earlier I tried -accel tcg,thread=multi,tb-size=1 and second cpu hang
>> under Linux was still here ...
>>
>> Interesting, booting full gentoo 2007 distro with those icount options
>> make usb keyboard add many chars at single push :)
>>
>> but so far this one works, even if prints  bunch of "warning, guest is late"
>>
>> netbsd10$ ~/src/qemu/build/qemu-system-ppc64 -bios 
>> ~/obj-ppc/openbios-qemu.elf
>> -M mac99,via=pmu  -cdrom ~/ISO/install-ppc-minimal-2007.0.iso     -L
>> /usr/pkg/share/qemu/  -d guest_errors,unimp -icount
>> shift=4,align=on,sleep=on -cpu g4  -smp 2 -boot d -display sdl -g
>> 1024x768x8
>> cpus[0] = 0x71c6ee438540 0x71c6ee43b0c0
>> cpus[1] = 0x71c6ee057a00 0x71c6ee05a580
>> Warning: The guest is now late by 0.0 to 1.0 seconds
>> Warning: The guest is now late by 1.0 to 2.0 seconds
>> Warning: The guest is now late by 2.0 to 3.0 seconds
>> Warning: The guest is now late by 4.0 to 5.0 seconds
>> Warning: The guest is now late by 6.0 to 7.0 seconds
>> Warning: The guest is now late by 8.0 to 9.0 seconds
>> Warning: The guest is now late by 10.0 to 11.0 seconds
>> Warning: The guest is now late by 12.0 to 13.0 seconds
>>
>> bigger value of align=N (5,6) makes those warnings go away, but guest
>> become much slower :)
>>
>> But at least it detects both CPUs reliably now.
>>
>> Now trying to boot BSDs
>
>
> with -smp 2 and various -icount shift=N values
>
>
> FreeBSD still get its reboot, and NetBSD still hang at cd detection.
>
> both boot ok with -smp 1
>
> But at least Linuxes made some progress today!
>
> Idea about trying -icount  found here:
>
> https://github.com/zephyrproject-rtos/zephyr/issues/14173
>


Now, i added this sleep(1) call

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);


and Gentoo 2007 starts up with two processors :)

 ~/src/qemu/build/qemu-system-ppc64 -bios ~/obj-ppc/openbios-qemu.elf
-M mac99,via=pmu  -cdrom ~/ISO/install-ppc-minimal-2007.0.iso     -L
/usr/pkg/share/qemu/  -d guest_errors,unimp  -cpu g4  -smp 2 -boot d
-display sdl -g 1024x768x8 -accel tcg,thread=multi,tb-size=1000
cpus[0] = 0x7c1deeca12c0 0x7c1deeca3e40
cpus[1] = 0x7c1deec25200 0x7c1deec27d80

I can run two opnessl speed in two terminals and host cpu load go to
~200% (186 to be exact)
More tests pending



>
>
>
>>
>>
>> >
>> > > smp_core99_probe
>> > > [    1.379097] PowerMac SMP probe found 2 cpus
>> > > [    1.382170] PMU i2c /pci@f2000000/mac-io@c/via-pmu@16000
>> > > [    1.383239]  channel 1 bus <multibus>
>> > > [    1.383801]  channel 2 bus <multibus>
>> > > [    1.384927] Processor timebase sync using GPIO 0x73
>> > > [    1.385810] mpic: requesting IPIs...
>> > > [    1.389626] CPU0: L2CR is 0
>> > > [    1.467632] rcu: Hierarchical SRCU implementation.
>> > > [    1.468170] rcu:     Max phase no-delay instances is 1000.
>> > > [    1.482467] Timer migration: 1 hierarchy levels; 8 children per
>> > > group; 1 crossnode level
>> > > [    1.539868] smp: Bringing up secondary CPUs ...
>> > > smp_core99_kick_cpu
>> > > smp_core99_kick_cpu done
>> > > [    1.580818] CPU1: L2CR was 0
>> > > [    1.581107] CPU1: L2CR set to 0
>> > > [    1.594300] smp: Brought up 1 node, 2 CPUs
>> > > [    1.635304] Memory: 102756K/131072K available (14004K kernel code,
>> > > 1384K rwdata, 6476K rodata, 1580K init, 494K bss, 25932K reserved, 0K
>> > > cma-reserved, 0K highmem)
>> > > [    1.723621] devtmpfs: initialized
>> > > [    1.877665] Found UniNorth PCI host bridge at 0x00000000f2000000.
>> > > Firmware bus number: 0->0
>> > >
>> > > ~/src/qemu/build/qemu-system-ppc64 -bios ~/obj-ppc/openbios-qemu.elf
>> > > -M mac99,via=pmu  -kernel ~/boot/vmlinux-6.12.17   -L 
>> > > /usr/pkg/share/qemu/  -d
>> > > guest_errors,unimp -nographic -icount shift=6,align=off,sleep=off -cpu
>> > > g4 -append "console=ttyPZ0" -smp 2
>> > >
>> > >
>> > > so may be timing issue after all ?
>> > >
>> > > Does TCG no-op delay too fast ?
>> >
>> > I don't know, I hope not everybody is ignoring the thread now and there
>> > are still some people reading who can add some insight here.
>> >
>> > Regards,
>> > BALATON Zoltan