Alright. So. I got fed up with trying to figure out why Windows was acting the way it was. So I undid everything I did. I went in reverse through all the guides and removed everything. Completely removed the passthrough. Short of reinstalling Fedora from scratch it was gone.
Then I went through the guides again, this time using pci-stub instead of vfio drivers. I set up a new Windows 8.1 VM, fully updated it, added the card to the VM, and installed the Nvidia drivers.
Same exact problem. Both Windows 8.1 VMs do the exact same thing. They boot fine, I get through the boot screen with the spinning dots, then, when it should go to the login screen, the monitor goes to sleep and the console screen delays for about 5 to 10 seconds then displays the login screen.
For the life of me I can't figure out why the monitor is going to sleep. After doing all this I am fairly certain it is a Windows/driver problem, not a host passthrough problem. But I don't know what it is.
Yeah, sure sounds like it, try this, when it's finishing post before you get the Windows screen start pressing the F8 key (make sure your keyboard is captured by the the console...) then if you get the Windows boot menu choose safe mode and see it it will boot on into Windows, if it does then yeah it's a video driver problem. At that point you can look around in device manager and see what Windows is loading and if it has any problems, you might look at the Windows error log if you don't see a problem in device manager.
I can't get F8 to get me to the Windows options screen. It either only gives me the UEFI options, or is ignored during boot.
I don't see anything in the logs of importance. No errors. There is an information level log saying the driver "dam" didn't load at startup, but I think that is for touchscreens or something. Apart from that, nothing.
In device manager it shows both the GTX 970 as well as Microsoft Basic Display Adapter under Display Adapters, and both are "working."
As dumb as it might sound....but which type of connector are you using to connect to the monitor? HDMI, DVI or VGA, there has been issues of flakiness using HDMI with this type of setup, it works sometimes with some cards and not at all for others, just a thought.
Are you talking about vfio-pci versus the pci-stub driver? I don't think there any difference that would affect guest performance. My understanding is that pci-stub and vfio-pci are like placeholder drivers for devices while the guest is not running and the host has control of the hardware. They prevent the host kernel from loading actual drivers for the hardware which may break passthrough. Neither are actually needed if no drivers for passthrough devices are included in the host kernel or modules.
I believe vfio-pci has some extra functionality compared to pci-stub for handling attaching and detatching the device more gracefully, and also supports some lower power states for devices while the guest is down.
I haven't had time to really play around with this for the past few days. Lots of family stuff over the holiday.
I did try it once, on Saturday, and found a pretty debilitating problem. When I hold the arrow key (or any key for that matter, probably) for more than a few seconds the display starts stuttering and freezing, and I get this horrific sound out of my speakers. As soon as I release the key the display goes back to normal and the sound goes away. If I do it a few times in a row the mouse stops working completely.
Not sure what caused this. I switched back to using vfio, and it made no difference. I am currently doing a clean (re)install of the nvidia drivers, in case it's something funky with them. Later tonight or tomorrow I will also find a USB keyboard and a spare USB mouse and pass them through to the VM, to see if it's my Model M or Logitech wireless mouse that it suddenly doesn't like. Apart from that, I am not sure what to do.
Edit: Yup, definitely something with the keyboard/mouse. Sharing between the host and guest worked fine before, and now it doesn't. Going to make it more clunky and less convenient to have two sets of keyboard and mice on the desk.
Yeah...defiantly will suck, question, did you load drivers in your guest for the keyboard and mouse or are you using the virtual drivers provided by QEMU - vert-manager? I know my G-13 game pad had a lot of weird quirks until I loaded the software for it in Windows/guest, that pretty well solved all my issues including creating and saving/loading key profiles for each game. The mouse I do use two but it's mainly because I use a old trackball for my host system that doesn't have Windows support or software anymore but I refuse to give it up (it works just fine in Linux but has polling issues in windows)...lol
The Windows guest never asked for specific drivers. It installed generic PS/2 drivers for both the mouse and keyboard. That's what they are set up as in the VM setup, generic PS2 devices, and I can't change or remove them. I can add generic USB devices, but it still won't let me remove the PS2 versions.
Shouldn't need to remove them, but you might try loading the software in Windows I know the G-13 on my system is listed as a USB game pad (or USB input device) in vert-manager, but Windows does see it for what it is, but then again I did load software for it to have the key profile/programming function. If you have specific software for the keyboard and mouse it can't hurt to install it in the guest then reboot the guest and see if Windows finds the device. It could also be a function of your keyboard, not sure what it would be but it sounds like it's repeating the key stroke when you hold the key down filling the keyboard buffer...but that is just a guess.
Just passing through the second keyboard and mouse to the VM works OK for now. I actually bought a PCI-e x1 USB 3.0 card and plan on passing that through to the VM with all the peripherals I need.
Everything has been very stable the last few days. At first the Windows VM and host could turn their respective monitors off after a set time of inactivity, but now the Windows VM won't do it. Not sure why, and I am afraid it will burn in the screen just sitting there.
Great......the monitor issue might be in your Windows power settings, but I'm not totally sure, I just manually turn my monitor off, as far as burn in I don't really think that is a issue on LCD panels like it was on CRTs at least I've never seen it happen to a LCD panel, one of our PCs here at work has basically the same screen on for 10 hours a day 5 days a week 52 weeks a year (accounting software) and has never burnt that image into it.
Yeah, it's weird. The settings in the VM don't change; it's always set to 5 minutes. It'll work for awhile, then it won't. The host had a problem with turning the monitor off too, but it's been doing it fine for a few days now.
Just in case anyone wants to go down the vfio route, I found this little tidbit of information that really cleans up and streamlines the assigning of devices to the vfio driver.
In the guide I followed (and linked to far up the thread somewhere) the author made a conf file in modprobe.d that told the system which devices to assign to the vfio driver at boot. He did this using a huge string of characters that was, frankly, confusing. I tried doing this with a PCI-e USB 3.0 card yesterday, and couldn't get it to work.
In the conf file, instead of: options vfio-pci ids=1002:ffffffff:ffffffff:ffffffff:00030000:ffff00ff,1002:ffffffff:ffffffff:ffffffff:00040300:ffffffff,10de:ffffffff:ffffffff:ffffffff:00030000:ffff00ff,10de:ffffffff:ffffffff:ffffffff:00040300:ffffffff
just put: options vfio-pci ids=10de:13c2,10de:0fbb,1912:0014
This example is actually what's in my modprobe.d/local.conf file. It successfully passes through my video card, the audio component of the video card, as well as my new PCI-e USB card.