GPU passthrough extremely bad performance, USB controller fails to load driver

User Support Hardware Issues
, , ,
1

The quick summary is that I can get GPU passthrough “working”, but it is extremely slow. The desktop takes minutes to load, if it loads at all, and is so slow that it’s unusable when it does load. I am able to get things working using QEMU/KVM with the same hardware. I’m not sure how to continue troubleshooting.

I’d greatly appreciate any help. Please let me know if there’s any more information I can get that’d be helpful for troubleshooting this issue.

Details

Qubes

I’ve mostly been following this guide at Create a Gaming HVM. I made a post there describing some of my issues and what I’ve tried a few days ago:

As I mentioned in that post, I was able to get things working using a nvidia GPU without any apparent issues. I’m currently trying to get things working with an rx 6750 xt. I’m currently testing on Ubuntu 23.10, but I don’t have any distribution preference right now, I’m just trying to get it working on any linux distribution.

As a guest in qubes, the behavior seems to been fairly consistent across distributions. I get errors like:

amdgpu 0000:00:05.0: [drm] *ERROR* [PLANE:70:plane-5] commit wait timed out
amdgpu 0000:00:05.0: [drm] *ERROR* [CRTC:91:crtc-0] flip_done timed out
amdgpu 0000:00:05.0: [drm] *ERROR* flip_done timed out
amdgpu 0000:00:05.0: [drm] *ERROR* [CRTC:91:crtc-0] commit wait timed out
amdgpu 0000:00:05.0: [drm] *ERROR* flip_done timed out

I get output through the GPU, but it takes several minutes for the desktop to load, and it is so slow that I can’t really do anything. Mouse movements are smooth, but even doing something as simple as clicking and dragging on the desktop makes everything very choppy.

I’ve tried multiple kernel versions with manjaro specifically and by using the kernels that different distributions are on, but I haven’t noticed any of them making a difference.

I’ve tried a variety of kernel options, but unfortunately I haven’t recorded every one that I’ve tried. I’ve almost always used pci=nomsi, but I have tried a few times without it just in case that was the issue.

I’ve tried a few BIOS options:

  • sr-iov on/off
  • resizable bar on/off
  • explicitly setting some virtualization options enabled instead of to auto

With the BIOS options, I also didn’t notice any changes other than a message in dmesg complaining about resizeable bar being off when it has been off.

Baremetal

To make sure that there wasn’t a hardware issue, I booted off a fedora live CD using the GPU output. I didn’t notice any issues.

QEUM/KVM

To try to test to see if this was an issue with the this specific GPU being virtualized, I booted off of a fresh fedora install on a usb SSD, installed @virtualization, installed an Ubuntu 23.10 VM, and then passed through the GPU.

I was able to play a youtube video without any issues, but I did notice an issue on the desktop.

Clicking and dragging on the desktop made everything choppy, but not as bad as in the qubes guest. Clicking on a window to resize it, or releasing after also caused a split second hang, but actually resizing the window didn’t cause any issues. Watching system monitor while clicking and dragging around the desktop showed a single core CPU utilization spike to 100%, so it seems that for some reason the desktop is using software rendering despite the GPU being the only display output.

At some point the host went to sleep. After waking the host, the guest had no output and was showing similar flip_done timed out errors as qubes guests do at boot. I’m not sure if this is related to whatever is happening in qubes. If it is, it seems like there might be some issue with guests waking the GPU from sleep, and something about the way the GPU is passed to the guest by qubes or xen is different than the way QEMU/KVM passes it, causing the issue to happen immediately with qubes guests but only after a host sleep with the QEMU/KVM guest.

A few times when shutting off the QEMU/KVM guest, virtual machine manager freezes and it seems that this is because the gpu failed to reattach to the host. I’m not sure how to recover from this, even host shutdown hangs and it has to be power cycled.

USB controller

I am not sure if this is related or might help find the issue, I’m including it just in case.

I have a Renesas uPD720201 based USB controller that I’m also trying to pass through. To try to focus on one issue at a time, I have not been passing it to the qubes VM while trying to work on the GPU issue.

When I do try to pass it to a VM in qubes, with or without a GPU, it fails. I get error -110 and lspci -k shows no driver in use. I tried to find the cause of this and on another forum someone suggested updating the firmware, which I did, but it did not fix the issue.

The controller can be passed to the KVM VM without any issues.

Like the GPU, the controller is in its own iommu group.

Configs and logs

Qubes

<domain type='xen'>
  <name>ubuntu23</name>
  <uuid>d32c3c8a-31e1-413d-89df-c20a144c036a</uuid>
  <memory unit='KiB'>4096000</memory>
  <currentMemory unit='KiB'>4096000</currentMemory>
  <vcpu placement='static'>2</vcpu>
  <os>
    <type arch='x86_64' machine='xenfv'>hvm</type>
    <loader type='rom'>hvmloader</loader>
    <boot dev='cdrom'/>
    <boot dev='hd'/>
  </os>
  <features>
    <acpi/>
    <apic/>
    <pae/>
    <viridian/>
    <xen>
      <e820_host state='on'/>
    </xen>
  </features>
  <cpu mode='host-passthrough'>
    <feature policy='disable' name='vmx'/>
    <feature policy='disable' name='svm'/>
    <feature policy='require' name='invtsc'/>
  </cpu>
  <clock offset='variable' adjustment='0' basis='utc'/>
  <on_poweroff>destroy</on_poweroff>
  <on_reboot>destroy</on_reboot>
  <on_crash>destroy</on_crash>
  <devices>
    <emulator type='stubdom-linux' cmdline='-qubes-audio:audiovm_xid=0 -qubes-net:client_ip=10.137.0.60,dns_0=10.139.1.1,dns_1=10.139.1.2,gw=10.138.35.186,netmask=255.255.255.255'/>
    <disk type='block' device='disk'>
      <driver name='phy' type='raw'/>
      <source dev='/dev/mapper/qubes_dom0-vm--ubuntu23--root--snap'/>
      <script path='/etc/xen/scripts/qubes-block'/>
      <target dev='xvda' bus='xen'/>
    </disk>
    <disk type='block' device='disk'>
      <driver name='phy' type='raw'/>
      <source dev='/dev/mapper/qubes_dom0-vm--ubuntu23--private--snap'/>
      <script path='/etc/xen/scripts/qubes-block'/>
      <target dev='xvdb' bus='xen'/>
    </disk>
    <disk type='block' device='disk'>
      <driver name='phy' type='raw'/>
      <source dev='/dev/mapper/qubes_dom0-vm--ubuntu23--volatile'/>
      <script path='/etc/xen/scripts/qubes-block'/>
      <target dev='xvdc' bus='xen'/>
    </disk>
    <controller type='xenbus' index='0'/>
    <interface type='ethernet'>
      <mac address='00:16:3e:5e:6c:00'/>
      <ip address='10.137.0.60' family='ipv4'/>
      <script path='vif-route-qubes'/>
      <backenddomain name='sys-firewall'/>
    </interface>
    <console type='pty'>
      <target type='xen' port='0'/>
    </console>
    <input type='tablet' bus='usb'/>
    <input type='mouse' bus='ps2'/>
    <input type='keyboard' bus='ps2'/>
    <hostdev mode='subsystem' type='pci' managed='yes'>
      <driver name='xen'/>
      <source>
        <address domain='0x0000' bus='0x03' slot='0x00' function='0x0'/>
      </source>
    </hostdev>
    <hostdev mode='subsystem' type='pci' managed='yes'>
      <driver name='xen'/>
      <source>
        <address domain='0x0000' bus='0x03' slot='0x00' function='0x1'/>
      </source>
    </hostdev>
    <memballoon model='xen'/>
  </devices>
</domain>

cat /proc/cmdline

BOOT_IMAGE=/boot/vmlinuz-6.5.0-9-generic root=UUID=bf61702b-336e-4dc1-ba38-e364f19271d5 ro pci=nomsi quiet splash vt.handoff=7

Output of sudo dmesg is attached as qubes-ubuntu-dmesg.log. qubes-ubuntu-usb-dmesg.log is for a boot with the usb controlled attached.

qubes-ubuntu-dmesg.log (83.8 KB)
qubes-ubuntu-usb-dmesg.log (127.3 KB)

KVM

<domain type='kvm'>
  <name>ubuntu23.10</name>
  <uuid>decd318f-8d3e-491e-a290-e074fd2bc240</uuid>
  <title>Ubuntu 23.10</title>
  <metadata>
    <boxes:gnome-boxes xmlns:boxes="https://wiki.gnome.org/Apps/Boxes">
      <os-state>live</os-state>
      <media-id>http://ubuntu.com/ubuntu/23.10:0</media-id>
      <media>/home/user/Downloads/ubuntu-23.10.1-desktop-amd64.iso</media>
    </boxes:gnome-boxes>
    <libosinfo:libosinfo xmlns:libosinfo="http://libosinfo.org/xmlns/libvirt/domain/1.0">
      <libosinfo:os id="http://ubuntu.com/ubuntu/23.10"/>
    </libosinfo:libosinfo>
  </metadata>
  <memory unit='KiB'>4194304</memory>
  <currentMemory unit='KiB'>4194304</currentMemory>
  <vcpu placement='static'>24</vcpu>
  <os>
    <type arch='x86_64' machine='pc-q35-8.2'>hvm</type>
    <boot dev='cdrom'/>
    <boot dev='hd'/>
    <bootmenu enable='yes'/>
  </os>
  <features>
    <acpi/>
    <apic/>
  </features>
  <cpu mode='host-passthrough' check='none' migratable='on'>
    <topology sockets='1' dies='1' clusters='1' cores='12' threads='2'/>
  </cpu>
  <clock offset='localtime'>
    <timer name='rtc' tickpolicy='catchup'/>
    <timer name='pit' tickpolicy='delay'/>
    <timer name='hpet' present='no'/>
  </clock>
  <on_poweroff>destroy</on_poweroff>
  <on_reboot>destroy</on_reboot>
  <on_crash>destroy</on_crash>
  <pm>
    <suspend-to-mem enabled='no'/>
    <suspend-to-disk enabled='no'/>
  </pm>
  <devices>
    <emulator>/usr/bin/qemu-system-x86_64</emulator>
    <disk type='file' device='disk'>
      <driver name='qemu' type='qcow2' cache='writeback' discard='unmap'/>
      <source file='/home/user/.local/share/gnome-boxes/images/ubuntu23.10'/>
      <target dev='vda' bus='virtio'/>
      <address type='pci' domain='0x0000' bus='0x04' slot='0x00' function='0x0'/>
    </disk>
    <disk type='file' device='cdrom'>
      <driver name='qemu' type='raw'/>
      <source file='/home/user/Downloads/ubuntu-23.10.1-desktop-amd64.iso' startupPolicy='mandatory'/>
      <target dev='hdc' bus='sata'/>
      <readonly/>
      <address type='drive' controller='0' bus='0' target='0' unit='2'/>
    </disk>
    <controller type='usb' index='0' model='qemu-xhci' ports='15'>
      <address type='pci' domain='0x0000' bus='0x02' slot='0x00' function='0x0'/>
    </controller>
    <controller type='sata' index='0'>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x1f' function='0x2'/>
    </controller>
    <controller type='pci' index='0' model='pcie-root'/>
    <controller type='pci' index='1' model='pcie-root-port'>
      <model name='pcie-root-port'/>
      <target chassis='1' port='0x10'/>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x02' function='0x0' multifunction='on'/>
    </controller>
    <controller type='pci' index='2' model='pcie-root-port'>
      <model name='pcie-root-port'/>
      <target chassis='2' port='0x11'/>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x02' function='0x1'/>
    </controller>
    <controller type='pci' index='3' model='pcie-root-port'>
      <model name='pcie-root-port'/>
      <target chassis='3' port='0x12'/>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x02' function='0x2'/>
    </controller>
    <controller type='pci' index='4' model='pcie-root-port'>
      <model name='pcie-root-port'/>
      <target chassis='4' port='0x13'/>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x02' function='0x3'/>
    </controller>
    <controller type='pci' index='5' model='pcie-root-port'>
      <model name='pcie-root-port'/>
      <target chassis='5' port='0x14'/>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x02' function='0x4'/>
    </controller>
    <controller type='pci' index='6' model='pcie-root-port'>
      <model name='pcie-root-port'/>
      <target chassis='6' port='0x15'/>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x02' function='0x5'/>
    </controller>
    <controller type='virtio-serial' index='0'>
      <address type='pci' domain='0x0000' bus='0x03' slot='0x00' function='0x0'/>
    </controller>
    <controller type='ccid' index='0'>
      <address type='usb' bus='0' port='1'/>
    </controller>
    <interface type='user'>
      <mac address='52:54:00:aa:98:d9'/>
      <model type='virtio'/>
      <address type='pci' domain='0x0000' bus='0x01' slot='0x00' function='0x0'/>
    </interface>
    <smartcard mode='passthrough' type='spicevmc'>
      <address type='ccid' controller='0' slot='0'/>
    </smartcard>
    <serial type='pty'>
      <target type='isa-serial' port='0'>
        <model name='isa-serial'/>
      </target>
    </serial>
    <console type='pty'>
      <target type='serial' port='0'/>
    </console>
    <channel type='spicevmc'>
      <target type='virtio' name='com.redhat.spice.0'/>
      <address type='virtio-serial' controller='0' bus='0' port='1'/>
    </channel>
    <channel type='spiceport'>
      <source channel='org.spice-space.webdav.0'/>
      <target type='virtio' name='org.spice-space.webdav.0'/>
      <address type='virtio-serial' controller='0' bus='0' port='2'/>
    </channel>
    <input type='tablet' bus='usb'>
      <address type='usb' bus='0' port='2'/>
    </input>
    <input type='mouse' bus='ps2'/>
    <input type='keyboard' bus='ps2'/>
    <graphics type='spice'>
      <listen type='none'/>
      <image compression='off'/>
      <gl enable='no'/>
    </graphics>
    <sound model='ich9'>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x1b' function='0x0'/>
    </sound>
    <audio id='1' type='spice'/>
    <video>
      <model type='qxl' ram='65536' vram='65536' vgamem='16384' heads='1' primary='yes'>
        <acceleration accel3d='no'/>
      </model>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x01' function='0x0'/>
    </video>
    <redirdev bus='usb' type='spicevmc'>
      <address type='usb' bus='0' port='3'/>
    </redirdev>
    <redirdev bus='usb' type='spicevmc'>
      <address type='usb' bus='0' port='4'/>
    </redirdev>
    <redirdev bus='usb' type='spicevmc'>
      <address type='usb' bus='0' port='5'/>
    </redirdev>
    <redirdev bus='usb' type='spicevmc'>
      <address type='usb' bus='0' port='6'/>
    </redirdev>
    <watchdog model='itco' action='reset'/>
    <memballoon model='virtio'>
      <address type='pci' domain='0x0000' bus='0x05' slot='0x00' function='0x0'/>
    </memballoon>
  </devices>
</domain>

cat /proc/cmdline

BOOT_IMAGE=/boot/vmlinuz-6.5.0-44-generic root=UUID=ed527a6f-fa79-49ad-b36e-14ce77dde89b ro quiet splash vt.handoff=7

Output of sudo dmesg is attached as kvm-ubuntu-dmesg.log

kvm-ubuntu-dmesg.log (67.3 KB)

2

Hi,
I had the same issue in the past and used some workaround that worked for me at the time.
However I do not have a AMD gpu anymore, so can’t test or be sure.
Some references that may help you:

1 Like
3

Thank you for the links, unfortunately I wasn’t able to find anything that solved the issue. Here’s some of the related things I’ve tried from the github issue:

  • I wasn’t able to get manjaro to boot on kernel 5.4.282-1, even with no pcie devices attached. I wanted to try this thinking it’d be easy to test, but I suspect that 5.4 doesn’t support the 6750 xt anyway. If someone thinks this is worth pursuing, I’d be willing to put more effort into getting it to run, maybe on another distro. I wasn’t able to find specifically what the minimum kernel version that that 6750 needs is, but the earliest version I saw mentioned with it was 5.15.
  • The qubes-ubuntu-dmesg.log I posted at the start of this topic is with pci=nomsi, but the issue is still there. It seems that someone on the github issue is saying that on qubes 4.2 there are still performance issues if pci=nomsi is used. They seem to be saying that the issues are fixed by using xen 4.17.2-8.58 from the unstable repo, but I’m a bit concerned about indefinitely using an old version of xen just to get GPU passthrough working.

I didn’t see anything else that I could try from the github issue. If I’ve missed anything, please let me know. From your post in the Ryzen 7000 thread:

  • Using a linux kernel below 5.10 seems to not be an option because of the GPU.
  • Qubes prevents me from not passing through the audio part of the GPU, it gives me an error.
  • I have tested with resizable bar disabled.
  • CSM support has always been disabled.

I did read through the rest of the Ryzen 7000 thread, but a lot of the things in there seemed to be related to getting qubes itself to work, not gpu passthrough. If I’ve missed anything please point it out to me.

Based on the latest reply in the github issue, it sounds like this is a xen issue and the only known fix right now seems to be an old version of xen with a custom patch.

It looks like there is some activity from early August related to that github issue. Unfortunately I’m not familiar enough with qubes or xen backend to be able to figure out if I can do anything with this or how far off it is from being released. If anyone can point me to any resources or information related to this, I’d appreciate that.

I’m still willing to try things if there are other suggestions, and I’m still willing to provide more information if I can get anything that might be helpful.

4

Try the xen version linked, if it solve your issue, it should not be an issue to integrate the patch that fix it into more recent xen version.

If that doesn’t work, you can try multiples drivers option referenced here: drm/amdgpu AMDgpu driver — The Linux Kernel documentation

5

The patched version does fix the issue with the GPU. What do I need to do to apply it to the latest xen version qubes uses?

Unsurprisingly since it seems like a separate issue, there’s no difference in the USB controller issue.

6

The patched version does fix the issue with the GPU. What do I need to do to apply it to the latest xen version qubes uses?

You should add a comment in the github issue.
The more technical part would be to check if the patch have already been integrated upstream or not.
If not, check why.
And add the patch in the git so that it is integrated.

And idk if you want to try that, but you can integrate it and compile it yourself in the meantime if you have the technical background required. ( I could give you pointer to what to look to compile and add the patch )

7

I think it was added to xen in 4.19 Xen Project Announces Performance and Security Advancements with Release of 4.19 - Xen Project and I’m assuming that this is to patch the version qubes uses Backport patch for MSI / PIRQ by marmarek · Pull Request #176 · QubesOS/qubes-vmm-xen · GitHub

I haven’t found any discussion about that PR and I don’t know what the normal process is for anything related to qubes development so I’m not sure why it hasn’t been merged yet, but it looks like there are some failing tests so that might be why.

I don’t have enough background to know where to begin in trying to integrate it myself while waiting for it to be done officially, but if there’s an existing guide for something similar I might be able to work it out. I’m capable of forking the repository and merging the changes into my fork, but I wouldn’t exactly know where to go from there. It looks like it uses qubes builder, which I’m sure is documented so I could probably figure out how to use it, but assuming that builds the packages that need to be replaced, I wouldn’t know how to deploy them.

8

I’ve been looking at things a bit with the patched xen version and noticed multiple issues. I’m assuming that these are unrelated to the patch, and I haven’t had the opportunity to try too much to fix them yet.

GPU Issues

Following the guide linked earlier, I’m able to get output through the GPU. Things like youtube videos play and I don’t notice any performance issues on the desktop.

vulkaninfo --summary shows the passed GPU and llvmpipe when the scrips to output through the GPU are not running, but it stops showing the passed GPU when the scripts are run. vkcube run from a terminal in the desktop on the gpu runs on the cpu instead of the gpu. I’ve only tried one game, but lutris/wine doesn’t seem to recognize the GPU and seems to try to do software rendering even though it’s running on the GPU’s display.

All I’ve tried so far is switching to the drivers provided by AMD instead of the ones packaged by debian, so unfortunately I don’t have much info right now. I’m planning on trying to check if a VM without qubes integration works or not.

Windows 10/11 don’t recognize the GPU. All I was able to find is error 43, which I think is the reset bug. I haven’t tried to find how people address this yet. I’ve tried is disabling and re-enabling the device in device manager, which causes it to report that it’s working but it doesn’t fix the issue. I tried to install AMD’s drivers, and those cause a bluescreen.

USB Controller

Surprisingly, the USB controller works in Windows 10/11 without issue. I don’t remember if I tested this before, so I’m not sure if the patch is related. It still doesn’t work in linux under qubes, I still get a -110 error. This would lead me to believe that it’s a linux driver issue, but as I think I mentioned earlier, I was able to get the USB controller working without issue with KVM, so I have no clue what’s wrong or how to fix it. The only thing I’ve been able to find is a firmware issue, but I’ve already made sure the firmware is up to date.

9

An update on the vulkaninfo issue: The GPU is visible if you run the command outside of the session going through the GPU or as root within that session, so it seems this might just be something like an xorg config issue.

Update: It looks like environment variables aren’t being set in the session using the GPU. I get the following errors at the top of vulkaninfo --summary:

error: XDG_RUNTIME_DIR is invalid or not set in the environment.
ERROR: [../src/amd/vulkan/radv_device.c:725] Code 0 : Could not open device /dev/dri/renderD128: Permission denied (VK_ERROR_INCOMPATIBLE_DRIVER)
error: XDG_RUNTIME_DIR is invalid or not set in the environment.
error: XDG_RUNTIME_DIR is invalid or not set in the environment.
error: XDG_RUNTIME_DIR is invalid or not set in the environment.
error: XDG_RUNTIME_DIR is invalid or not set in the environment.
error: XDG_RUNTIME_DIR is invalid or not set in the environment.
error: XDG_RUNTIME_DIR is invalid or not set in the environment.
10

To do that manually, the idea:

 - vmm-xen: 
     branch: msiamd
     url: https://github.com/YOURGITHUBACC/qubes-vmm-xen"
  • Since you are quickly testing your own build, you need to modify signature checking, to configure it properly to accept your GPG key ( or disable signature checking if you don’t want to spend time configuring it properly:
insecure-skip-checking:
 - vmm-xen

)

  • Build the thing
  • Copy the RPM package back to dom0
  • Install it
11

I’m using an AMD CPU with Nvidia GPU, and I’m having similar issues when using a standalone HVM installed from ISO. Initially, everything works just fine, but when I pass the GPU, the entire desktop starts lagging.

I’ve tested with Ubuntu+Wayland and Debian+X11, and it’s the same issue with both distributions. The GPU is working on both distributions, running test applications like vkcube shows the GPU is detected and used to run the application.

The funny thing is that everything works just fine when I use an HVM made from a Debian template, and the virtual hardware passed to both the ISO and template based HVMs is the same.

I couldn’t figure out why this is happening, one difference is the qubes x11 driver. The ISO installed distributions are using a modesetting driver, don’t know if that could be the issue. I also don’t know if the stubdom works the same why when using ISO.

One last things, with the template based HVM I can use hybrid graphics and get GPU acceleration in window mode, it could also be this feature that somehow doesn’t work when installing from ISO.

I also want mention, I don’t think the uPD720201 works with Qubes OS, I had a USB controller using the same chip, the chip just seems to have very poor Linux support.

12

The patch have been added to the qubes version of xen.

Switch dom0 to use testing repositories and update, and should be ok

13

Thank you for the update, glad this is making its way towards the stable release.

For an update to my earlier issues related to using the GPU within the VM, I was able to get things mostly working on Arch. I haven’t tried debian again since to try to figure out if it was a debian issue or if I was just doing something wrong with my setup there. I think I only have a handful of quirks to work around within Arch, and they seem to all be unrelated to the original issue:

  • Permissions issues when I tried connecting a game controller through sys-usb. I tried to troubleshoot this with the Arch wiki but wasn’t successful. I haven’t tried connecting the controller to a passed PCIe USB controller yet so I’m not sure where exactly the issue lies.
  • Sometimes I get no screen detected when I run the script to output to the GPU display. I suspect this is unrelated to qubes itself and has more to do with configurations within the VM.
  • Sometimes the qubes display integration doesn’t seem to work and I have to connect to the console of the GPU qube instead of being able to open the terminal application.
  • I somewhat regularly get an error when trying to connect the GPU to a VM after the first time in a host boot. It seems like this is probably being caused with a reset issue with this generation of AMD GPUs and the typical fix is to run a linux kernel module on the host that handles it. Since with qubes the host is xen not linux, I’ll have to try to figure out another solution.
  • Unfortunately I’ve still come no closer to getting the USB controller to work.

If I’m able to fix things I’ll try to make sure I get back with any solutions in case anyone else experiences the same issues

14

That’s unfortunate about the uPD720201. Hosts seem to have no issue with it so it seems like the issue is specific to virtualization. Do you know of any cards that work well with qubes?

For your desktop lag issue, try using a VM without any integration. During testing I was using pop os and ubuntu to try to exclude any issues qubes integration might be causing. It might be worth trying both windows and linux to see if either one works.

15

The VIA chips seem to work okay, I think it was the VL805 is used. I also had a card with a Fresco Logic chip, not sure what the specific model was, it also worked okay.

1 Like