OK, testing update:
Things have been going pretty well, but I have noticed the following:
- Passed through PCI audio device tends to click and pop a little bit in all apps, and YT videos get desynced (audio gets ahead of video by longer times as the video plays. Pausing and starting it gets it re-synced). Google searches indicated that recent versions of Win10 sometimes have this problem, but I am curious if it is Win10, or Win10 running on Qubes. Since the audio device is a PCI passthrough, I am inclined to think it is mostly in Windows. Running LatencyMon tells me that the system is not reliably fast enough to do real-time audio, due to lag spikes in certain DCP calls. I’m trying to track down which ones.
- Performance is pretty close to the previous windows-only setup I had before. Some things tend to take a longer time to load/start up, and there are still some intermittent latency issues.
- Mouse cursor movement still causes significant cpu usage (jumps by 10-20% on all vCPUs).
- I’ve noticed that even with 1-2 open apps, 200 processes and 3k threads, all vCPUs tend to jump up to 60-80% utilization fairly often.
- 3D game performance is spotty depending on the game, but all seem playable. 30-60FPS on fairly high settings. I figure once I stop passing through the mouse/keyboard and use the external switch onto a passed-through USB3.0 controller PCI device, it will be better.
Also, I have a serious issue when starting up Qubes. it doesn’t seem to be able to keep the same device ids across reboots. This manifests in three separate ways:
- network devices - no matter what, just about every time I boot, I have to term into sys-net and reassign the network connections to the correct devices. I have two ethernet ports, and one wireless one. On boot, the Public connection (going to my router) is on ens6, the next time, it is on ens8, and the wireless moves around as well. I know there is a way to use udev rules to force assignment based on mac address, but the udev rules are on the disposable filesystem, so they aren’t there when sys-net starts up. I suppose I have to put them into the FC37 template. Sometimes, it re-creates a new “Wired connection 1” that I have to delete and reassign. I have made a script to cleanly assign the devices manually, but the fact that it can’t remember this stuff from boot to boot is a pain.
- USB devices - I have assigned persistent usb devices to my Windows Qube. However, different reboots cause them to jump to different bus ids. One boot they are sys-usb:8-x, the next, they are 6-x, and now they are 5-x. I have to detach the old defunct ones, and attach the correct ones. Maddening.
- If a PCI device disappears for any reason (one of my USB 3.0 bus devices did this once), it re-jiggers everything, and both sys-net and qvm-usb/sys-usb have to manually reconfigured.
I guess this issue needs to be turned into a feature request for the linux kernel (and/or the associated USB/PCI device drivers and NetworkManager). It needs to remember device info on particular pci device id (via vendor:product codes and product names and serial numbers/mac addresses or other unique identifier) and not reassign everything to different internal ids so things that are connected logically to those devices don’t break every dang time.
Lastly, I had a networking failure in the Windows Qube tonight, and now when I start it up, it starts up, but the qrexec<>qubesd connection isn’t working, and networking inside Windows isn’t getting configured, so no network is available. I posted this in a new thread here:
On the upside, my fix to usb-export works to return the mouse/keyboard back to dom0 properly, even when the Windows qube crashes or is shut down normally, so I don’t need to use the kvmdetach batch script in Windows to restore it before shutting down. So, +1 for me there. 
Once I get the Windows Qube fixed, I will be working on the summary post for this thread. I think that, unless I see more instability or encounter other issues in the near term, this chapter can be closed.
Anyway, if anyone has any insights on one or more of these issues, please let me know and thanks for continuing to read my little Windows-on-Qubes travel blog. XD