What the fastest possible x64 emulation way of OS4 today ?

@balaton

I also compiled the latest version of qemu
official (8.1.1).
Without problems.

But if I use emulation it gives me a series of errors.
And qemu doesn't work with Pegasos2
So I went back to the branch
git clone http://scm.osdn.net/gitroot/qmiga/qemu.git

If necessary, I'll recompile qemu 8.1.1 and I can be more precise.
Showing the error.

If it's useful.

@balaton

this is the error that appears with the official version (8.1.1)

I compiled as per the branch version:
git clone http://scm.osdn.net/gitroot/qmiga/qemu.git

but in this case:
git clone https://gitlab.com/qemu-project/qemu.git

Then:
./configure --target-list=ppc-softmmu --disable-dbus-display --enable-slirp --enable-lto --enable-sdl --enable-gtk

here is the error:

qemu-system-ppc: ../ui/console.c:818: dpy_get_ui_info: "dpy_ui_info_supported(con)" assertion failed.
zsh: IOT instruction qemu-system-ppc -M pegasos2 -cpu 750cxe -accel tcg -kernel -initrd -m 2048

--------------------------------------------------------------

with "qemu":
qemu-system-ppc -M pegasos2 -cpu 750cxe -accel tcg -kernel /home/white/Downloads/bboot-0.4/bboot -initrd /home/white/Downloads/Kickstart.zip -m 2048 -serial stdio -device sm501 - drive if=none,id=hd,file=/home/white/Scaricati/32gb.raw,format=raw -device ide-hd,drive=hd,bus=ide.1 -netdev user,id=mynet0 -device rtl8139 ,netdev=mynet0 -drive if=none,id=hd1,file=/home/white/Scaricati/coffin.raw,format=raw -device ide-hd,drive=hd1,bus=ide.1 -display gtk,zoom -to-fit=on -full-screen -vga none

without using a real HD for example.

@white
I can't reproduce the same with SDL ui backend so try with -display sdl. This assert was added recently in commit
https://gitlab.com/qemu-project/qemu/- ... 5c8817fb18fb25650507b69f8
Report to qemu-devel list also cc-ing the patch author in Signed-off-by in the commit message or in QEMU bug tracker.

@afxgroup
Quote:
First of all, does the same work on real pegasos2? Just to rule out the possibility that this is a problem with AmigaOS or gprof in general and indeed related to emulation. If it works on real machine then how does it work? What processor features it relies on to collect the profiling info? Once you know that you can check if those are emulated correctly. Searching for similar problem found a bug that says this can happen when some timer interrupts are not happening but I don't know how to check that and which timer would it be. Or it could also rely on some debugging feature of the CPU that's not emulated. Maybe trying with -cpu G3 could be useful as older CPUs probably had less exotic features so higher chance they are working better.

On real peg2 everything is working correctly. It seems that an interrupt is never called and so profiling doesn't work correctly. Or better. Time is always zero. While function count is working correctly. I don't know if you need more informations. However I don't know how performance monitor works internally and which registers are used. But I'm almost sure that interrupt is never executed

@afxgroup
Which interrupt? Where can you see it's not called? From the QEMU side you can enable either -d int which logs every CPU interrupt that will be a flood of logs so probably won't be able to find anything in it unless you know what to look for or -trace enable="pic*" to get logs about the ISA PICs or there are "info irq" and "info pic" commands in QEMU Monitor to get some info but one would need to know again what to look for for these to be useful.

@balaton
Quote:Minimal requirements for the gprof code used by the C libraries and the PerformanceMonitor.resource parts used by it should be the timer and debug registers (TBU, TBL, TCR, TSR, DBCR0, DBCR1, DBCR2, DBSR) and the timer and debug related interrupts.

@balaton

I don't know the internal details because I don't have access to the kernel source code. I can only try to explain to you how the code is working now:

https://github.com/afxgroup/clib2/blob ... /library/profile/profil.c

On line 110 you have:
IPM->SetInterruptVector(1, &CounterInt);

That is enabling that interrupt (CounterInt is an Interrupt) and that should call CounterIntFn function.
But while on a real pegasos2 that function is called, on qemu is never called. So I suppose that interrupt is never enabled

If you tell me how, I could try to "grep" something useful for you.

@afxgroup
I still don't know what hardware interrupt would IPM->SetInterruptVector(1, &CounterInt); hook into. You could check in info irq if that interrupt happens but that lists hardware interrupt numbers so first we would need to know what hardware interrupt this means then we can check if that's generated.

@balaton

I tried the various options
down to the simple:
./configure --target-list=ppc-softmmu

the problem remains (qemu 8.1.1)

the only option that works is not giving the error:
qemu-system-ppc: ../ui/console.c:818: dpy_get_ui_info: "dpy_ui_info_supported(con)" assertion failed.
zsh: IOT instruction qemu-system-ppc -M pegasos2 -cpu 750cxe -accel tcg -kernel -initrd -m 2048


this,
it doesn't return any errors but I've never seen the point of using it:

qemu-system-ppc -M pegasos2 -cpu 750cxe -accel tcg -kernel /home/white/Downloads/bboot-0.4/bboot -initrd /home/white/Downloads/Kickstart.zip -m 2048 -serial stdio -device sm501 -netdev user, id=mynet0 -device rtl8139,netdev=mynet0 -drive format=raw,file=/dev/sdf -display sdl,gl=on -device virtio-gpu-gl-pci -vga none

I'll go back to using the branch:
git clone http://scm.osdn.net/gitroot/qmiga/qemu.git

@white
Report the problem to QEMU otherwise it will never be fixed.
Also what about -display sdl -vga none -device sm501 Does that give error to? Then without -vga none just using -device sm501 ? Maybe it's because we don't have default vga that's causing a problem but I don't get that with QEMU master and -vga none -device sm501 so maybe 8.1.1 is missing some patch that's in master. The QEMU people who broke this should know better so just let them know.

@afxgroup
Quote:That code more or less uses the following features of PerformanceMonitor.resource:
Interrupts are caused when bit 0 (LSB) of the TimeBase register flips from 0 to 1. IIRC the TimeBase is running at 1/4 of the FSB speed, i.e. the interrupts are caused with a frequency of 1/8 of the FSB.
Interrupts are enabled for the current task only, when another task is executed no interrupts are caused.

That part of PerformanceMonitor.resource might even work without debug registers and interrupts, but I guess it doesn't even start if the CPU doesn't the support the debug registers and interrupts.
Did you check if OpenResource("performancemonitor.resource") succeeds? There checks, for CPUs like 440ep without support for it, disabling profiling if IPM is NULL.

@balaton

Thank you
but I don't know how to do it,
I never reported any errors.
if not to say it directly to you.

I use qemu as a simple user

note:
I imagine that as soon as the Windows x64 version is compiled the same error will happen.

@balaton
Quote:1 is the counter number, not an interrupt number.
https://wiki.amigaos.net/amiga/autodocs/performancemonitor.doc.txt

It's either the TimeBase interrupt or the Debug interrupt, both are CPU internal interrupts.

@white
Go to qenu.org and read there. You can either send an email to qemu-devel@nongnu.org and cc Marc-Amdre who was in the patch signed-off-by as he wrote the series that now asserts or you can create a ticket in QEMU's bug tracker on gitlab (I've never used that and won't get notified about bugs entered there but maybe some people check there so for this issue that should also work).

@joerg
I think timebase should work as that's widely used, the debug interrupt may more likely have some issues. Once that's confirmed to be used here somebody could read the CPU docs to understand how this is supposed to work then write a test case to check or check the code in qemu/target/ppc/ to see if it's emulated correctly (as that code emulates all CPUs it may be hard to find without detailed knowledge).

@balaton
No time to check or even fix sources, but the following 3 or 4 interrupts may be required ("Chapter 7 Interrupts and Exceptions" in Book E).
Timer:
IVOR10 Decrementer
IVOR11 Fixed-Interval Timer Interrupt
IVOR12 Watchdog Timer Interrupt (probably not used by AmigaOS)
Debug:
IVOR15 Debug

Quote:The code used by the C library gprof parts my not, but PerformanceMonitor.resource needs working debug registers and interrupts, for example you can even count "Number of CPU cycles" (PMCI_CPUCycles), "Number of CPU finished instructions" (PMCI_Instr), "Number of instructions completed by FPU" (PMCI_FPUInstr), etc. with it, which is only possible with the debug control/status registers and the debug interrupt but not a timer interrupt.

@balaton
Here's an account that resembles what happens to me
data 13 September 2023.

https://www.mail-archive.com/qemu-devel@nongnu.org/msg988673.html

@white
OK so then they already know about the problem and hopefully will be fixed eventually. Until then either use 8.1 or QEMU master from git if you want to test latest changes. Amigaone is only in my qmiga repo for now.

@joerg
IVORs are a BookE thing so only valid for sam460ex but not applicable for pegasso2, there are probably similar fixed exceptions for some of these (or they work differently on BookS PPC is closer to).

For the performance monitor features I haven't checked but maybe QEMU does not emulate these and some of them might not even be possible such as cycle count given that QEMU is not cycle exact and even getting number of executed instructions may be difficult considering that QEMU JITs guest code into TCG opcodes which it compiles to host code then runs it possibly from cache so it may be difficult to correlate code that's run to guest instructions so I would not be surprised if these are missing and may not even be possible to implement.

If profiling can work with just a timer and the problem is that this timer interrupt is not raised that may be fixable but if it needs full performance monitoring support in CPU that may only work with KVM on PPC host not under emulated PPC. All this is still just guessing so any of the above could be wrong but looks likely.