Cool, as long as it doesn’t add latency. The whole point for me was having a full quality sound card passed through for proaudio to a Windows guest - without a latency increase. Some of these USB3 audio interfaces can do <5ms now.
I dont have Pop!_OS, but Ubuntu 20.10.
Allready had qemu with omvf and passthrough running, but when I added a second r9 280x to the system I was unable to figure out how to pass only one of them to a VM. By using your initramfs script, I now have that working perfectly. There is only one issue I am hoping someone could help with.
I have 2x r9 280x and one RX550. One 280x is handed to amdgpu and used for host desktop. One RX550 is bound to vfio-pci and is passed to a windows vm. The last 280x is added to the override script, and is then passed to a VM.
This works perfectly, untill I reboot the VM with the 280X. When the VM shuts down, for some reason the gpu gets handed to the host, wich immediatly initializes and binds it to amdgpu driver. I can then start the VM again, and it will actually get unbound from amdgpu driver automatically, and the VM boots fine. However, if I reboot a second time, I end up with a reset bug, and the GPU will be unusable untill I reboot the host.
The RX550 bound by vfio-pci, handles unlimited reboots, and never gets initialized by host.
So, to my question. Is there some way to keep the host from seizing the gpu when vm gets shutdown? I belive thats what causes the reset bug in this case.
Is VFIO possible on a Razer blade 2019 base w/gtx1660ti? using Ubuntu 20.04LTS as host.
It appears that no Iommu groups are showing up on my system. I have not found any other posts with a similar issue. The output of the IOMMU script on my ROG STRIX Z390-H mobo (with VT-d enabled) is as follows:
IOMMU Group * 00:00.0 Host bridge [0600]: Intel Corporation 8th Gen Core 8-core Desktop Processor Host Bridge/DRAM Registers [Coffee Lake S] [8086:3e30] (rev 0a)
00:01.0 PCI bridge [0604]: Intel Corporation Xeon E3-1200 v5/E3-1500 v5/6th Gen Core Processor PCIe Controller (x16) [8086:1901] (rev 0a)
00:01.1 PCI bridge [0604]: Intel Corporation Xeon E3-1200 v5/E3-1500 v5/6th Gen Core Processor PCIe Controller (x8) [8086:1905] (rev 0a)
00:14.0 USB controller [0c03]: Intel Corporation Cannon Lake PCH USB 3.1 xHCI Host Controller [8086:a36d] (rev 10)
00:14.2 RAM memory [0500]: Intel Corporation Cannon Lake PCH Shared SRAM [8086:a36f] (rev 10)
00:16.0 Communication controller [0780]: Intel Corporation Cannon Lake PCH HECI Controller [8086:a360] (rev 10)
00:17.0 SATA controller [0106]: Intel Corporation Cannon Lake PCH SATA AHCI Controller [8086:a352] (rev 10)
00:1b.0 PCI bridge [0604]: Intel Corporation Cannon Lake PCH PCI Express Root Port #17 [8086:a340] (rev f0)
00:1c.0 PCI bridge [0604]: Intel Corporation Cannon Lake PCH PCI Express Root Port #1 [8086:a338] (rev f0)
00:1c.5 PCI bridge [0604]: Intel Corporation Cannon Lake PCH PCI Express Root Port #6 [8086:a33d] (rev f0)
00:1d.0 PCI bridge [0604]: Intel Corporation Cannon Lake PCH PCI Express Root Port #9 [8086:a330] (rev f0)
00:1f.0 ISA bridge [0601]: Intel Corporation Z390 Chipset LPC/eSPI Controller [8086:a305] (rev 10)
00:1f.3 Audio device [0403]: Intel Corporation Cannon Lake PCH cAVS [8086:a348] (rev 10)
00:1f.4 SMBus [0c05]: Intel Corporation Cannon Lake PCH SMBus Controller [8086:a323] (rev 10)
00:1f.5 Serial bus controller [0c80]: Intel Corporation Cannon Lake PCH SPI Controller [8086:a324] (rev 10)
00:1f.6 Ethernet controller [0200]: Intel Corporation Ethernet Connection (7) I219-V [8086:15bc] (rev 10)
01:00.0 VGA compatible controller [0300]: NVIDIA Corporation GP102 [GeForce GTX 1080 Ti] [10de:1b06] (rev a1)
01:00.1 Audio device [0403]: NVIDIA Corporation GP102 HDMI Audio Controller [10de:10ef] (rev a1)
02:00.0 VGA compatible controller [0300]: NVIDIA Corporation GP102 [GeForce GTX 1080 Ti] [10de:1b06] (rev a1)
02:00.1 Audio device [0403]: NVIDIA Corporation GP102 HDMI Audio Controller [10de:10ef] (rev a1)
05:00.0 SATA controller [0106]: Marvell Technology Group Ltd. Device [1b4b:9215] (rev 11)
Any thoughts?
@wendell you could add https://github.com/duncanthrax/scream to Audio section as option.
I use Scream over year now and I didn’t had any problem, there is no CPU usage, quality is good and there is no latency, it uses same technology as Looking Glass, it uses IVSHMEM for sharing audio data between guest and host.
And for VM input (like KVM switch) I use evdev --> https://passthroughpo.st/using-evdev-passthrough-seamless-vm-input/ it is built into kernel, so it is efficient and no latency here.
@wendell
here is a alternative way to passthrough devices based on IOMMU groups:
#!/bin/sh
PREREQS=""
IOMMU_GROUPS=""
## e.g. IOMMU_GROUPS="22 27 24" or IOMMU_GROUPS="22"
if [ ! -z "$(ls -A /sys/class/iommu)" ]; then
for IOMMU_GROUP in $IOMMU_GROUPS;
DEVS="$(ls /sys/kernel/iommu_groups/$IOMMU_GROUP/devices)"
for DEV in $DEVS; do
echo "vfio-pci" > /sys/kernel/iommu_groups/$IOMMU_GROUP/devices/$DEV/driver_override
done
done
fi
modprobe -i vfio-pci
Also kernelstub is what you’d normally use in Pop!_OS:
sudo kernelstub -a amd_iommu=on\ iommu=pt
and bootctl to check the status:
sudo bootctl status | grep options
1 Like
Noice! Heads off newbs having issues and my way let’s old geezers not pass through everything in certain edge cases. Caveat: iommu groups can change between bios updates
1 Like
A 2nd try at this 
#!/bin/sh
PREREQS=""
DOMAINBUSS="0000:01:00 0000:0d:00"
## e.g. DOMAIN:BUS(:SUB) DOMAINBUSS="0000:0d:00 0000:0c"
if [ ! -z "$(ls -A /sys/class/iommu)" ]; then
cd /sys/bus/pci/devices/
for DOMAINBUS in $DOMAINBUSS; do
DEVS="$(ls -d $DOMAINBUS*)"
for DEV in $DEVS; do
echo "vfio-pci" > $DEV/driver_override
done
done
fi
modprobe -i vfio-pci
I am just trying to find a way to make it more convinient to swap gpus and addin cards by having it all being passed through without concern for a specific pci device layout
1 Like
Ohh that gives me an idea for a vfio test bench. You rock!
1 Like
You’re very welcome 
Bumping this thread because the conclusion to the LTT Linux Daily Driver challenge has me quite sour in the mouth over trying to use Wine, Proton and Lutris.
Are there plans to offer a tutorial for basic GRUB rather than systemd boot? I would probably spin up a Kubuntu 20.04 LTS machine to do this on my new i9-10920X system.
1 Like
Hello everyone, I just upgraded to pop os 22.04 and everything seems to have went fine besides looking glass no longer works. I’ve made absolutely no changes and I’m getting the following error when trying to run the client.
/looking-glass-client: error while loading shared libraries: libbfd-2.37-system.so: cannot open shared object file: No such file or directory
Sorry if this is a stupid question, I may just try to rest everything up or wait for a few days to see if anyone else has a similar issues. Any help is appreciated in pointing me in the right direction, thanks in advance.
::edit::
Well I was dumb, I just rebuilt the client and voila it worked.
1 Like
Something interesting seems to have happened, inspired by u/whstwd, I found a virtual display driver that even helps me to use looking-glass without plugging any video output to the dGPU.
And u/whstwd claims that this thing also works for notebooks using muxless solutions.
And I found that there seem to be open source implementations of virtual displays.
Strange to say, it seems that this dummy display driver does work, but I’ve only used this on my 1050Ti, does that mean we don’t need to buy an HDMI dummy plug? And the virtual display driver is more friendly to muxless laptops than the HDMI dummy plug.
@gnif, what do you think?
I wouldn’t recommend using such a tool. The tool that you have linked here involves compiling it yourself, and because you very likely do not have a code signing certificate, to load it you will need to disable windows driver security enforcement (test-sign mode). This is a bad idea for two reasons,
- your system is susceptible to malicious drivers if you disable it.
- Anti-cheat software will flag your system as “modified” and refuse to run.
We have had an Indirect Display Driver on the LG wish list for some time now and if it ever gets funded we will have it native
It’s certainly good if LG has relevant development plans, but now I need to evaluate the availability of virtual displays, and after I import the root certificate, this tool seems to be available.
As an aside, can virtual displays support freesync? And will virtual displays add additional performance overhead?
It doesn’t work like this, the windows kernel will only accept drivers that are co-signed by the microsoft CA that is hard coded into the kernel.
I do not know if this is necroing. but I need some assistance with this tutorial.
Probably, I have no idea if Wendell has updated this, the tutorial is from 2019 and a lot of things have changed since then. Linux is unfortunately a moving target for better and worse.
What is the exact problem?