Blog index–Rollingš„blog–Permalink
"Wtf? Jake, I am not reading all this text. Give it to me straight: is it worth it to GPU passthrough?"
Honestly? In my opinion? ... It's fun to set up! Passing the GPU to and from a VM involves restarting X each time which is annoying but since I'm GAYMING its not that bad, but sometimes I think I might as well just dual-boot. But I hate Windows too much to do that. So, this is mainly for bragging rights.
I have began to replay a game I haven't played in a long time since that game doesn't work with Proton. It's a bitter-sweet nostalgic trip - the game isn't as good as I remember.
Recently I have began playing a video game. It isn't too graphic intensive and Steam's Proton handles it perfectly. Except for one small, tiny, miniscule detail: my operating system isn't Windows so, obviously, I am not allowed to access the online features of this game. But I want to access the online features of this proprietary game...
This leaves me with either: hacking Proton and somehow tricking Easy Anti Cheat (EAC) or installing Windows, either dual-boot or through a Virtual Machine (VM). (Some anti-cheat software, like EAC, run along the Windows kernel as a kernel module to make sure you aren't 'cheating'. :)
I am not smart enough to hack Proton, additionally I strongly dislike the idea of having to restart my computer just to play video games and reboot into */Linux when finished, so rather than dual-boot I decided to install Windows into a VM. I will passthrough my GPU which would allow me to play video games almost as if Windows was on 'bare-metal'... Almost like it.
Here I will note some things that are useful to know in a situation like mine:
$ lspci -knnv | grep -e '\[....:....\]\|IOMMU\|Kernel' | sed -e '/Subsystem/d' -e 's/\(.*\)IOMMU\(.*\)/\tIOMMU:\2/'` With Arch it is a simple matter of accessing my package manager to download and install linux-zen since Arch officially supports the Zen kernel (they provide a binary so I do not have to compile it).
However, this may be naught if you decide you need to do some RDTSC trickery so you'll end up compiling a kernel anyway - it is a lot easier than you might think but definitely time consuming. In my case, EAC doesn't ban VMs so I did not bother patching any RDTSC trickery.
Passing the GPU while I had a spare GPU for GNU/Linux is pretty easy. But I was not happy with this configuration because my monitors had insufficient amount of plugs... My main monitor only supports 1 VGA and 1 DVI. My TV 'monitor', only 1 HDMI, 1 VGA, and 1 RCA. Neither of my GPU's support VGA so it wouldn't be possible to tell my main monitor to change it's source which would've been the easiest solution.
In other words, one half of my monitors would be off unless I always use a VM. This annoyed me, so I decided that I will stick with one GPU and that I will pass that to and from a VM. This is known as single GPU passthrough, for which there are many tutorials for. With this configuration, I pass through my main GPU to Windows (even though I was using it previously!) and use the motherboards iGPU for displaying GNU/Linux.
I ended up having to dump the bios of the GPU I was using, a Nvidia card, because when I would try to start the VM the GPU would have an `error 43`. Remote desktop helps in identifying these situation. You could use Spice too, I suppose, but at that time I didn't use my motherboard's iGPU (I probably should've. Hindsight is 20/20). Fortunately, after commanding Windows to shutdown, the GPU would be successfully passed back to the host and X would restart, using QEMU + Libvirt hooks. So, at least, that was half of the battle done.
When I was trying to dump the bios of my GPU (and nothing was using it, including vfio-pci as I unbinded it prior to dumping) and I was greeted with `cat: rom Input/output error`. I found that setting the kernel parameter 'vfio-pci.disable_idle_d3=1' and running '# setpci -s 01:00.0 COMMAND=2:2' would allow me to dump the rom. Afterwards I ran '# setpci -s 01:00.0 COMMAND=0:2' though I am uncertain how important that is. I made sure to remove the kernel parameter as well.
Another detail that I've seen is to open the resulting rom file in a hex-editor and look for something that starts with `VIDEO` and delete everything above the `U`. Everything - all they way to the top. However, I did not need to do that since my dump didn't contain anything above the `U`. However for this advice was for Nvidia cards, I am not sure about AMD.
Some tutorials recommend booting into Windows 'bare-metal' and using a program called GPU-Z but I haven't tried this.
As of this date, Dec 19 2021, I can confirm that EAC (at least implemented for Xenoverse 2) doesn't ban VM users but they may decide to change their mind in the future. If that happens I will hopefully learn my lesson about playing proprietary games and will never do it again. Doubtful though.
An aside: I had a paragraph explaining that Windows doesn't properly shutdown GPUs when it itself shuts off thus resulting in instability but I discovered that actually it was a bug in Mesa that was causing graphical glitches rather than passthrough doing anything weird. This paragraph serves no purpose but to remind myself in the future that maybe it is just the software. Though with AMD, this is a legitimate concern since their GPUs have reset bugs. There are some work-arounds for them: Window Pro allows one access to 'shutdown scripts' that Windows will run prior to shutting itself off where you can turn off the GPU. If you don't have Windows Pro or better then you aren't allowed access to the shutdown function, and need to fork out several hundred dollars to upgrade. However, there is a host side option called vendor-reset but I do not know much about how it would work.
However; at least with my AMD GPU the reset bug only happened with Windows. I could restart my VM that ran GNU/Linux Mint over and over and over and the AMD GPU would still work. But when I booted into Windows, uh oh! Nothing works anymore! :'(
An additional aside: AMD's Adrenaline, when trying to install the driver for a minimum of 10 minutes, it has so, so, so many ads. The AMD installation failed for me so I decided to poke around in the logs and discovered that AMD attempted* to send analytics to Google! What a different world from package managers. Also, I very much dislike it that they replaced every driver link to their Adrenaline software.
"Why yes, I would like to download software that is half a GB big with the sole purpose of downloading and installing drivers for me! It is too hard to just download the specific driver for my specific GPU and click install. I am just too stupid for it!" - Imaginary person that AMD created and somehow believes we are him.
With Nvidia... I know they get a lot of hate for how they treat the */Linux community (well deserved IMO), however installing the specific driver for my GPU on Windows was very easy, even if it was in the second-slot. It was so easy I actually cannot remember anything noteworthy about it. Nvidia had a page for that specific GPU that contained the driver, whereas AMD decided that made too much sense. Gotta make those 3Ā¢ per ad, don't you know?!
Note: * = attempted to, since the guest was subject to the host's `/etc/hosts` :)
If you wanted to view my XML sheet and hooks for some reason:
win10.xmlDue to abuse (the comments you see now are not abuse), commenting will be disabled for sometime. Send an email or something.