@balaton

I don't know if this helps at all, but I've uploaded vfio_* trace logs from the time of guest boot until the GPU test 16.


https://ufile.io/yf28ui39 (30Mb)

PS: I have passed through only the VGA controller (00:01:00.0) of my GPU, as the Audio Device (00:01:00.1) is not even recognized(?) by AmigaOS4.

@Hans

I barely understand a thing. But does this mean that we have a clue now?

When I start the qemu-system-ppc process it turns the card to the legacy IRQ mode INTx:


When I stop the process, I see no difference. But when I reboot the host system, it gets back to (which means MSI?):

@balaton

I tried to use Linux and Windows guest with QEMU, but I must have messed up my host system so much, both in OS and UEFI, that installations do not even start using VFIO.

When I run the qemu-system-x86_64 process, my host's monitor, which uses the integrated Intel GPU, gets crazy. This means that Windows and everything graphic turn to a strange multicolour pattern as if the integrated GPU is malfunctioning. I see a "flash" on the guest's monitor, but it doesn't start booting.

When I stop the QEMU process, the host's monitor turns back to normal, and the artifacts are gone.

I have to reset UEFI settings and some of the OS settings and try again.

@Capehill

This is the one for science, using Radeon RX550 as the guinea pig:
https://ibb.co/mvX14CZ

@Capehill
Quote:
I'll do it and inform you.

@Hans
Quote:
I'm the poor canary flying into the mineral mine tunnel to see if toxic gas exists further inside. Let's see if I die...

I even cleaned the connectors and PCIe slot with Isopropyl 90. I found the (hidden) mvme SSD, removed it, and placed it in another slot away from the CPU. (in case it was using PCIe lanes as read). What else can somebody do, I wonder.


Could be a problem that I don't do Single-GPU passthrough? I use the integrated GPU for my host and I pass the RX550 through QEMU/VFIO, plugged in a second monitor for the guest OS.

@balaton @Hans

Before running the QEMU process, the command sudo lspci -vv -s 0000:01:00.0 shows this:



After running the command:


The command sudo lspci -vv -s 0000:01:00.0 shows this:



Before:


After:


GRUB Configuration:


Is this a problem, or is it expected?

@Hans

Running this script with:
- R7 240 attached, took about: 24 seconds.
- RadeonRX 550 attached, took about: 1.50 or 2 seconds
- RadeonRX 550 attached with Screenmode --> Enable Interrupts = Checked, took about: 1.0 or 1.5 seconds
- RadeonRX 550 attached with Screenmode --> Enable Interrupts = Checked and Ethernet attached and using bochs-display, took about: 1.0 or 1.5 seconds (same as the test above)

When I enable interrupts on Screemode, the systems seem to run slower overall, though this test appears to execute faster.

(Nobody can switch hardware on the fly and run the test faster than me )

@Hans

Yes, of course. I'll try it with both GPUs, and I'll get to you with the results.

@Hans

Quote:

No, I tried all the possible combinations, and it didn't go any faster. The only thing that maybe helped a little was removing bochs-diplay and using Evdev for USB devices.

Also, the command:

Made a visible difference. But just a bit.

I also tried a funny thing using a real vga-to-vga on a small old monitor I found. I got the error "Couldn't create screen mode." I think this monitor supports 640x480.

@Hans

Quote:

Okay, so do I have to remove the ethernet from the QEMU command only, or should I also shut down the ethernet on the host? Regarding the USB drive, I have a secondary real SSD drive on "/dev/sdb" that I use in the QEMU command. Is this OK? For the mouse/keyboard, I use bochs-display. Is this OK, too?

@balaton
Indeed, virsh makes it more complex. So, I will create a new QEMU setup for this when I have time.

@balaton
Quote:
Ok, you motivate me. :)

@balaton
Quote:
Accepted, I don't think it could work either.

@balaton
About the --accel kvm --> --accel tcg on the Win VM are you sure it is so straightforward?

I converted the virsh Windows 11 VM XML to native Qemu.

Changed the --accel kvm to --accel tcg. The qemu command is very extensive and does not work from the command line. Libvirt must do some extra work before running the command.

@Hans

Quote:

Yes, I can understand that. If this is the case, as an extremely ultimate and desperate try, I would propose that you and @balaton take control of my desktop via Anydesk/Google Meet/Teamviewer when you are available. You can also view my hardware and UEFI settings in real-time using my mobile phone camera and direct me accordingly. Due to my job obligations, I can only be available in the afternoons and weekends.

If you judge that this approach could help the situation, you tell me.

@Hans

I got a bit overwhelmed during the weekend.

The scope of this problem is so broad that somebody could write a 20-page technical report only to sum up all the possible implications, including combinations of the cases that have already been tested, along with the detailed results so that they can be assessed afterwards. I don't think such a process can occur in public (or private) forums.

In addition, the Amiga OS and GPU driver copyrights raise a barrier that does not leave much room for forming any kind of hobby cross-party team.

The complexity of this issue gives me the impression that it resides in the "Amiga" side (that fragmented into a thousand pieces of companies & copyrights thing) to form a team of devs with qualifications similar to yours and @balaton 's (and possibly a hobbyist-volunteer beta tester like me!), to write code both on QEMU & OS/GPU driver sources in order to support it (like Microsoft, RedHat(IBM), etc, do). The opposite may not be a viable solution for this particular problem as it might need to be approached with a well-structured "Assess-Plan-Do-Reassess" procedure.

@joerg

No, R7 240 is much slower in this host. It's not being able to start the Workbench components like Amidock. It took 3 minutes to load the workbench completely.

Over and out. I need to forget.

@Hans @balaton

While running the GPU test, I see in the host isolated core that the "Local Timer Interrupts" number is growing by about 5000 per second. Does this might indicate that the CPU core is used heavily during the GPU test?

@geennaam had mentioned that

Quote:

I'm using a much inferior Ryzen 3200G with x8 PCI slot. I wonder if the usage of a much powerful CPU + doubled PCI lanes solves the problem or just hides it.

@joerg

Hello, indeed I will try the R7 240 next.

But the overhead that is being introduced by VFIO GPU passthrough in contrast with the emulated sm501 can't be justified.

VFIO PCI just passes the control of the device to the guest. The QEMU process, as I read, does only this thing.

Also, there must be a difference in RadeonHD.chip and RadeonRX.chip on how they handle the GPU resources, because R7 240 VRAM <=> RAM collapses, as @Hans mentioned, but the drawing is faster.

I'm ignorant of GPU resource handling and development, but my humble thought is that it does not make sense for a much, much inferior card to perform better on drawing.

Another thing that makes the difference is the compositing effects switch. If I use GPU passthrough and have this enabled, the AOS4 freezes at some point completely, no matter what GPU I use.

If I disable GUI --> compositing effects, I have a slow but working environment.

I mentioned before that the zTools package I got from Amistore contains a Sysmon app. In the GPU view, there is a "compositing" field. The value of this field is "inactive." Of course, in this emulated environment, trusting the guest organs (Ranger, Cpu_watcher) has already been proven wrong.

I update the new Host machine specifications

CPU
- Model: AMD Ryzen 3 3200G (Picasso) FP5(BGA-1140, 12NM,
-Instructions: MMX(+), SSE(1, 2, 3, 3S, 4.1, 4.2, 4A), AVX(1, 2), FMA(3), AES, CLMUL, RdRand, SHA, AMD-V, x86-64
- Cores: 4

On chip GPU:
Picasso/Raven 2 [Radeon Vega Series / Radeon Vega Mobile Series]
VBIOS: 113-PICASSO-115
Interface: PCIe Gen3x16 (current) / Gen3x16 (max)
Driver: amdgpu

Secondary GPU:
Lexa PRO [Radeon 540/540X/550/550X / RX 540X/550/550X]
Driver vfio-pci

On chip caches:
- L1: 32 kB, 8-way associative, 64-bytes line size
- L2: 512 kB, 8-way associative, 64-bytes line size
- L3: 4 MB, 16-way associative, 64-bytes line size

Motherboard
ASRock A320M-HDV R4.0
Bios American Megatrends Inc. P4.00 07/16/2020
Chipset: Advanced Micro Devices, Inc. [AMD] FCH LPC Bridge

Operating System
- Arch Linux
- Kernel: Linux 6.9.7-zen1-1-zen

RAM
- 2 x 16GB


PS: @balaton
Quote:
I changed the domain type from kvm to tcg. It didn't start, but I didn't try anything more. I'll unplug the RX550 from the New host, replug on the Old host and I will try things, and it will work eventually. But I don't know if it is needed anymore after the latest news...

It is a no...

https://hdrlab.org.nz/benchmark/gfxbench2d/OS/AmigaOS/Result/2820

But despite what is says, they system is 3-4 times more responsive. I still see drawing and drawing but it's visibly faster.

Game over?

@balaton @Hans

I'm watching your posts, but I didn't respond because I was on an 11-hour marathon with Qemu/AOS4.

In order to rule out the possibility that my host machine is not working as expected for QemuPPC/VFIO GPU/AmigaOS4.1FE, I prepared a new setup on a new machine with ArchLinux as the host OS. The ArchLinux installation was unimaginably complex (as it has nothing preinstalled and preconfigured). In fact, I installed every package I needed, including any configuration from networking to Xorg to display manager, etc, by hand, thanks to its fantastic documentation. Anyway.

New machine's Specifications:
- AMD Ryzen 3200 CPU
- ASRock Motherboard
- Integrated VEGA 8 GPU
- 32 GB RAM
- I plugged the Radeon RX550 (planning to use it as a secondary GPU for Vfio passthrough).

Yes, it is (much) slower than my previous host machine in terms of CPU performance. But I hope it can handle a single-core OS like AOS4 well enough. And indeed until now I don't see any difference...

(I will update the specifications, providing more details later)

It seems to go faster, but it might be a placebo effect. So, I run the GPU tool right now and will post the results.

For now, I think I want to inherit Amigans Defender's signature.

"I'm so tired..."

@balaton

I've also included the other two patches, with no visible difference reflected in the GPU test.
https://hdrlab.org.nz/benchmark/gfxbench2d/OS/AmigaOS/Result/2817

Regarding the RadeonRX.chip version, I own the AOS4.1 Pegasos Edition and the Enhancer Software v2.2. I've also run the Enchancher's updater. The RadeonRX.chip 2.12 is the most updated version I get.