I think performance counters of PPC CPUs aren't emulated with TCG and it's proabably not easy to implement as it runs JIT compiled code so it does not know how many guest instructions it corresponds to which the performance counters should count. A sampling profiler that does a backtrace periodically should work but tools that rely on performance counters won't work. I think this was discussed before.

QEMU has one thread per vcpu and a main thread. If the vcpu always runs code it will be busy. If it also does some IO like accessing emulated hardware registers then the main thread will also have to run. This may explain why waiting for IO may lower the vcpu usage as then the vcpu may sleep instead of running the idle loop.

It looks like this may also be an issue on real machine which would use more power and keep the system run hotter instead of letting the CPU sleep when idle so maybe it should be fixed for the real machine too independent of QEMU. (Unless it does use something that works on real machine but not emulated by QEMU.)

@Redlion
AmigaOS version numbers and updates are confusing. There was original 4.1 then up to 6 updates to that then came 4.1FE (Final Edition) that contained all previous updates but then 4.1FE also had update 1 and 2. So it may be trying to install 4.1FE Update 1 and then 2 if your CD is the latest 4.1FE version. I don't think there was a release after 4.1FE but I could be wrong. I can't comment on errors during the update but it may be due to the lack of nvram emulation. If NVGetVar command from shell crashes you may need to replace it with some script that does nothing together with NVSetVar to avoid the errors or replace the nvram.resource.kmod in Kickstart with the Pegasos2 version (which can be found in the Updates) that does not try to access nvram. Or maybe just check what the update script does after it tries to access nvram and finish those steps by hand.

Sound works on amigaone and pegasos2 by default but the on-board sound of sam460ex is not emulated so for that machine you need to add a sound card with -device ES1370 which works with the SoundBlaster128 driver (then you may need to set it up in AHI prefs; there's some quirk in that pref that some uints need to be assigned to audio.device while some others to the SoundBlaster128 driver to get mixing working so more than one app can use sound at the same time but I don't remember which unit needs what; I think you'd leave those which are already use audio.device unchanged and change only those that are set to none or SM502 or similar to the SoundBlaster128 driver).

The sam460ex firmware has a bug that it does not boot with a USB drive attached so you should remove the "-usb -device usb-ehci,id=ehci -device usb-storage,bus=ehci.0,drive=usbdisk" options and only leave the "-drive if=none,id=usbdisk,format=raw,file=amigahd.img" option that defies the drive. Then after booting enter QEMU monitor with Ctrl+Alt+2 and issue "device_add usb-storage,drive=usbdisk" command which should plug the USB device that should then appear in AmigaOS (you can change back to the virtual machine with Ctrl+Alt+1).

@nikitas
I don't see anything extraordinary in the log (but I also don't really know what to look for). It seems using legacy interrupts may disable mapping of BARs so it may use slower I/O to access those but that still does not explain the slow speed you got also when others already manged to get better results.

Did you try other things that was mentioned above such as not using taskset and remove cpu isolation and irq pinning (or at least allocate 3 CPU cores to QEMU)? Or the tests Georg has described both with x11perf and in the last post above assigning the card but not loading the driver and see at which point it becomes slow (just to locate which component does something that could make is slow).

@Hans
The QEMU vfio device should do all that managing interrupts, from the guest it should appear as a normal PCI interrupt. There could be problems however if there is a problem somewhere passing through the interrupts. But I think if other PCI interrupts work, the vfio-pci device uses the same way so it should work too on the PCI side of it. I don't know about the vfio side. We're also passing a PCIe card as PCI to the guest so it may be an unusual config that's not well tested. As long as the guest does not try to access PCIe parts it might work though. There are some traces in QEMU's vfio that could be enabled, look in qemu/hw/vfio/trace-events. You can enable all of them with -trace enable="vfio*" but that might generate a lot of logs. Some logs might also be in the Linux kernel logs as vfio is handled there. Maybe there are some clues that could be get from those?

@Hans
Maybe the HD card could work if MicroDelay didn't have a problem with that card. This might mean these cards are slow for different reasons. It's also possible that problem with HD card is not actually in MicroDelay but could it be that something is disabling multitasking so the test runs slower even though the delay would return in time? What could do that with only the HD card but not RX card and how could that be confirmed? Maybe snoopy can log calls to Disable/Forbid and see if there are more of these with the HD card than RX card?

@nikitas
Here's some more motivation on what we might be able to achieve:



While QEMU uses one thread for vcpu it is multithreaded and has another thread for other tasks and maybe also an IO thread. So confining this to a single CPU core may not be a good idea. What if you drop all the tweaks of isolating CPU cores using taskset and setting irq affinity and just run QEMU normally? The host OS should be able to schedule the threads on its own.

Using other cards on the host should not interfere as long as they are in different vfio groups. Did you check vfio groups and established that the graphics card you're passing through is in its own group (with its sound function) and you pass all devices in that group? Also re-reading @geennaam's experiment in the long thread he used multifunction=on for the graphics function to create it as multifunction device as the sound part is at the same ID and another function of the card. I don't think that matters but have no better idea now.

@Hans
Quote:
Most of the people who do this want to play games in a VM that run on Windows while they want to run Linux. So they want to have the most performance and use KVM and vfio. This may mean that using it with TCG is not tested that much and with PPC at all but that does not mean it should not work. Of course we're on uncharted territory, not many people run AmigaOS on QEMU and even less tried vfio GPU pass through so it's not something that was tested and known to work. Some people tried it before for MacOS but gave up because there the firmware is needed to run the FCode ROM of the Mac graphics card (or a suitable ROM for a PC card) for MacOS to even recognise the card but QEMU's OpenBIOS can't run FCode ROMs and real Mac ROMs don't run with QEMU. (I had patches to fix both of these but they aren't upstream so one can only experiment with it with applying patches from different places so only a few people even tried. Somebody once managed to get a Rage128Pro working but don't know if it was usable.)

@nikitas
Only remove from the QEMU command. It was said that if the guest has a USB disk as with the ufat shared folder then it ran slower with vfio for some reason. I don't know if @geennaam ever talked about a network card. It does (or should) not matter what you have on the host, the theory is that maybe having other PCI devices in the guest like USB or network card may interfere with interrupts from the graphics card. Now they are on different bus and we had several patches to fix this but who knows. This was with an RadeonHD card and used pci.1 so it's different than what you've tried but we have not better idea at the moment. So remove all -device usb-* and -device rtl8139 from QEMU command line and see if that changes anything.

@Hans
Nikitas did not have a USB vfat device in the commands but may try removing the network (but I think also tried that and it didn't help). On pegasos2 all these may share the same interrupt so maybe there's still an issue with these after all the patches and level sensitive setting in BBoot? Anyway trying to reproduce with Linux could avoid all these and check if the problem is only with how AmigaOS does things or independent of that.

@nikitas
The -accel tcg should work with a normal QEMU command. Why don't you run Windows with a similar command as you used for AmigaOS or run a Linux guest instead of Windows. Virsh just adds additional complexity here.

@Georg
To help testing, could you please share your Linux kernel options and xorg.config to show how to set up vesafb and the x11perf command again so others can reproduce that test without having to find out the right config?

Also if somebody has a compiler for AmigaOS could try to compile a test for MicroDelay and check if that works. I don't have the AmigaOS SDK installed so can't make test for that at the moment.

@nikitas
Quote:
I'll pass that. I don't think this would be very convenient or I could give better advice than over this forum. I'm also a hobbyist not affiliated with any AmigaOS or QEMU companies and do this in my free time. I could try to get a card and try it myself but I have no drivers for it and still have enough to do without that so I'd prefer somebody helping doing all the testing that takes the most time. With Hans it might be an issue with time zones as he's on the other side of the globe.

@Hans
Quote:
It might help if you could test this yourself but that would need you to set up a Linux host which seems you'd like to avoid. Or maybe try to search if vfio on Windows host is possible. It's a crazy idea but who knows, these days Windows can also run Linux programs.

@nikitas
Quote:
Reminds me of this cartoon:


As long as it's not proven it's caused by hardware or the host's firmware the rest is software we can modify so it should be fixable once we find what causes the issue.
Quote:
Forget about AmigaOS for now but if you still have some patience left you could try setting up any machine with any card (could be the AMD one with the HD card) and configure the card with vesa driver and ShadowFB=0 as @Georg suggested and measure the VRAM access without any QEMU and vfio using x11perf. If that's faster than what we get with QEMU then set up vfio and try a Linux guest (same as the host in first step) and see if it's slower/same. If it's the same try same Linux guest with -accel tcg. Then try to make similar config with PPC Linux guest and do the x11perf test with that. This is supposed to show what point speed is lost or if these all are fast then problem is likely in what AmigaOS does.

@Redlion

The mynet0 is just the id to bind netdev and card together. It can be anything. Maybe it's clearer to write it as -netdev user,id=unet -device rtl8139,netdev=unet The -netdev option defines a natwork backend called unet that then you bind to the emulated network card. There could be different cards with different backends. The -device option defines what network card the guest OS sees, the -netdev option defines what QEMU does with the packets. What is your problem with network in the first place?

I meant the driver from the 4.1FE CD not the original 4.1. Update 1 or 2 updated this driver that made it less stable with QEMU. To get the latest driver from the os4welt.de forum you need to register otherwise downloads are not available. But unless you have network connection that sometimes breaks with high traffic it's not this problem but something else.

For mouse problems you could try different -display options see qemu-system-ppc -display help for available options, maybe -display sdl can work better if available (maybe -display sdl,gl=on when have issues with scaling). Otherwise you could get a tablet driver that was posted here on the forum somwhere and try -device usb-tablet but that won't work without installing the driver first but I don't remember where that driver was posted.

@Hans
Quote:
Even if it won't solve the issue it would allow testing with pci.1 to make sure it's not working differently with different PCI buses.

Quote:
If those instructions are badly emulated maybe could cause slow down but I don't expect that to explain such huge bottleneck.

Quote:
That was with an HD card although Nikitas got the same slow result with an HD card too so maybe something with his host machine/firmware or Linux?

Quote:
Is there a way to test that?

Quote:
Power management issues that leave the card in lowest power setting as you suspected before? Where can one see the GPU clock value in the test results or where did you get this info from? With Linux guest there was also a PM related error.

But I think Nikitas also ran the Windows version of the benchmark and that worked so maybe it's something PPC specific.

@nikitas
Can you repeat the test with Windows using KVM, then the same Windows with adding '-accel tcg' to disable KVM and also with PPC Linux guest with x11perf if you can get any Linux version see the card and use vesafb instead of amdgpu which likely won't work or not present in the older Linux versions that boot in AmigaNG?

@Redlion
I think people found that latest rtl8139 driver in 4.1FE Update 2 may be a bit unstable so you may need to downgrade to the version from 4.1FE CD or there's an updated version published on os4welt.de forum that should work but I don't know if that's available from anywhere else other than this test version.

@afxgroup
OK if this laptop has both integrated and discrete graphics then you can pass through just the radeon chip but there may be issues:

- How are these connected? Normally both of these GPUs would drive the internal screen but the firmware or OS would switch between them. So it could be that when the Radeon chip is not used the integrated GPU is connected so you won't see the output of the Radeon chip. Is there a way to configure it to drive the display connector while the integrated GPU drives the laptop screen? If not you may need to enable discrete GPU so it's connected to the screen but not use it from the host and pass it through to the guest. I don't know how to do all that but maybe there are some tools or Linux settings to control the discrete GPU in such machines. I think the doc I've found was using a laptop with integrated Radeon GPU that it passed through to the guest so this problem with which display it's connected to was not a question in that case.

- The AmigaOS driver may need the BIOS but a GPU in a laptop might not have it's own BIOS as it could be part of the system firmware. I don't know what to do in that case. You could pass a ROM image with romfile property but it can't be any random ROM but something that matches the settings for the internal GPU (otherwise you may break it if it tries to program with wrong values not suitable for the chip; I don't think it allows to overdrive and permanently break the chip but likely won't work with just any ROM from a similar graphics card but it has to match the memory and clock settings of the internal chip). If the internal card has it's own BIOS ROM then maybe it's enough to add rombar=1 and maybe run QEMU as root.

@Hans
And Nikitas's benchmark results above say "RadeonRX.chip 2.12" so maybe an update is needed for it to work with pci.1. I don't know it that would help but at least we have an explanation for the error we get now and a possible fix to try. Which update includes v2.16 RX driver?

@nikitas
OK, thanks for testing. It at least fixes the IRQ problem so you don't have to disable it. This helps but that's not all of the problems. Also now pci.0 should be the same as pci.1 because I've asked to test with pci.1 to check IRQ problems. (Unless the driver does something different for PCI and AGP in which case using pci.1 might still be better but the issue with the driver would need to be fixed for that. I can't do that so @Hans will need to check if your driver version is already fixed or this is another case that needs a fix.)

Quote:
You can try that, these patches change different things. The first 3 patch series change AltiVec to use 128bit instead of 64bit so it may help with VRAM access with the default G4 but not with -cpu 750fx (or whatever is a good g3 CPU now). The other dcbz patch might help a bit with the same VRAM access but also with G3 cpu but I'll make a new version of that trying to improve it a bit but had no time for that yet. For now you can try these patches and see if they make a difference.