PCI pass through is the ability of a virtualized guest system to directly access PCI hardware. Pass through for dedicated GPUs has just recently been added to the Linux kernel-based virtual machine. Soon afterward, users began to find that switching on nested page tables (NPT), a technology intended to provide hardware acceleration for virtual machines, had the opposite effect on AMD platforms and slowed frame rate down to a crawl.
Annoyed by this [gnif] set out to to fix the problem. His first step was to run graphics benchmarks to isolate the source of the problem. Having identified the culprit in the GPU, [gnif] began to read up on the involved technology stack. Three days of wrapping his head around technical docs allowed [gnif] to find the single line of code that resulted in a faulty memory set up and to implement a basic fix. He then passed the work on to [Paolo Bonzini] at patchwork.kernel.org, who released a more refined patch.
The bug affecting PCI pass through had been around for ten years and had received little attention from the manufacturer. It gained prominence when graphics cards were affected. In the end it took one very dedicated user three days to fix it, and then another day to roll out a patch for Open Source operating systems. In his notes [gnif] points out how helpful AMDs documentation was. With the right to repair in debate, DRMed technical docs and standards locked behind paywalls, [gnif]’s story is a reminder of the importance of accessible quality documentation.
props to him, nicely done quickpatch
“DRMed technical docs”? What? Did you mean NDAed?
Both I guess, I frequently have specification requiring use of certificates to open…
NDA is a kinda DRM with trust that the agreement won’t be broken and thus the “digital rights” to the digitally encoded documentation is essentially “Managed”.
And off topic, a little:
One could commentate the Intel/AMD tech-race:
Intel starts the race with AMD being taken in for the ride,
Intel speeds well off ahead with AMD’s fan backing the race for x86 success,
AMD still behind but slowly catches up,
WOoooaaaa, what just happened! AMD just flew past Intel at an alarming rate,
Intel pulls some tricks out of their hat and gave themselves a boost,
Intel and AMD are head to head in this race and AMD have gained more fans,
Intel slowly taking over!
Intel maintains ahead,
AMD just got a boost in the game, On paper they’re just not quite ahead but in the game,
AMD just Ryzen!!! They’re gaining steam in the game and the papers are looking good!!!
The race continues….
{:-D)-}-<
Oh, that is supposed to have been read with a wacky-races theme tune and commentator voice. ;-)
Except the “D” in this case isn’t a necessary component as it would be in (D)RM. It just could have easily been print. It’s best keeping DRM separate from other forms of restriction instead of trying to make DRM into a “kind of” one-size fits all type of device.
Well done!
I feel like this is the exact same bug that got smashed 5 years ago… AMD graphics performance suckiness in the closed source drivers, and someone disassembled the linux and windows drivers to find the issue…
Continue reading →
“DON’T TELL ME WHAT TO DO! (TM)” – that teen aged kid.
Joking apart, the article is only just too short to TL;DR-link.
I’ve caused havoc with the moderation system around here and I’ve gotten pretty heavily moderated….So we don’t need more of my type…. Lets stick to the topic:
Yay, bug-fixes,
Well, it looks from the code upload like an oldskool point to windowed memory… the one where the pointer is mapped direct to the framebuffer, Like the old IBM 80386 VGA programming days, except without all those segmented addresses and far pointers to the abyss or a straight crash-N-halt.
Linux FTW,
Oh, I just remembered, such code in a mature modern OS, nice to get back to roots heh?
AMD Rules!
Well it is about speeding their Ryzen Hardware up for GPU-passthrough.
Intel Rules!
Without them we may have all been running on 7.5-bit machines powered by local nuclear reactors or something!
Pick a side…
AMD or Intel, as long as it can sustain above 2-2.2Ghz (Intel 3rd-gen, AMD AM2+) for longer than 20mins, then that is a good start.
It should be noted that that screenshot was the first benchmark I had done of the system. The kernel was still full of debugging messages and had a debugger attached to the qemu process. Here is one after cleaning it all up :)
https://www.3dmark.com/3dm/22880343