nvidia-kvm-patcher
nvidia-kvm-patcher copied to clipboard
sk1080
Automatic Repair
Hey man, love what you're trying to do.
I don't understand the nuances of this fix, but I'm curious if it should work for any hypervisor/host, assuming you're applying to to a Windows 10 x64 Guest? I've tried this numerous times and always end up coming back to Automatic Startup Repair.
My setup: i7-5820k 64GB DDR4 GTX 970 MSI X99A SLI PLUS
Host - Windows Server 2016 Datacenter - TP5 Guest - Windows 10 Pro Driver - 368.39-desktop-win10-64bit-international-whql
My resource for discrete device assignment: https://blogs.technet.microsoft.com/virtualization/2015/11/19/discrete-device-assignment-description-and-background/
Unsure if I've missed any pertinent details but if I have, let me know. I'll probably have this page up until I get this damn thing working....
Thanks,
Owen
It should... Does the computer bluescreen once before ending up in automatic startup repair?
EDIT: I need to test hyper-v though, might trigger additional protections
No blue screen unfortunately, just rebooting after driver installation completes and no joy.
Hmm, maybe some progress. Went offline, uninstalled default drivers and deleted driver software and then installed the nvidia driver after applying your patch. Rebooted, system came back okay but now I'm getting error code 52.
I'll see if going online and updating breaks it. At this stage, running wushowhide doesn't present an nvidia update to hide, so... Let's see.
Did you enable test signing? I don't see the watermark, but your window could be covering it.
Still think my cert stuff is pretty shaky. Could you paste a log of the script being run? Could also temporarily boot with signing off and see if it loads, which it should.
Could you take a screenshot of the driver tab under the properties for your graphics card?
Changed executionpolicy to "Bypass" just for the purpose of this, but here you go: output.txt
Screenshot coming up.
testsigning still off - not sure if that affects the Digital Signer portion...
Edit: testsigning on - Not digitally signed
Number of files successfully Signed: 0 Number` of warnings: 0 Number of errors: 1 Thats interesting. Let me see if I can find out how to cause that.
EDIT: Does this box have an internet connection? Uses it for timestamp.
Uhh, I shouldn't have been lazy. I'm pretty sure I didn't get that when I ran the script initially. I'll try this again properly, sorry.
Also test mode needs to be on, which should show a watermark at your lower right. I might have said "test signing" in the past.
Sorry, might have missed it that time through. I've been reverting frequently.
Patching this attempt: Test Mode enabled with default driver+software uninstalled.
I think the error was from the SignTool having no net connectivity - couldn't reach timestamp server.
Edit: Number of files successfully Signed: 1
Sounds like its actually loading it and it is failing. Suppose im going to need to setup a test environment with hyper-v. Could also try to expose hyper-v using kvm, think some kernel patches are required to implement some features first though.
I'm going to let windows update and do some other stuff. I'll be back to fiddle with this helplessly when that's done.
Thanks a lot for the time you've put in already!
Here's a bootlog for you, maybe you can see something in there that makes sense to you!
My computer can't even assign anything in hyper-v, probably due to the same reason causing me to have to use an acs override patch in linux, how unfortunate.
Apologies, give this one a crack. It definitely works as I've successfully passed my PCI NIC through.
https://blog.workinghardinit.work/2016/04/11/discrete-device-assignment-in-windows-server-2016-hyper-v/
I fail this requirement: Access control services (ACS) on PCI Express root ports.
Sorry for the slow reply- was away for work.
That's unfortunate to hear but thanks for giving it a shot anyway.
So while it didn't seem to cause any issues on my windows 10 test system, when I tried to port this to windows 7 I discovered that the driver spec really calls for the sys file to be signed itself, and not just the catalog. As windows 7 requires this, it has been added to the script. Id say this is worth a retest due to that, although I give no guarantees.
Sad to say that I have an identical issue running qemu / kvm with a Windows 7 guest.
I've applied your patch to the driver, everything signed fine, test mode is on (marquee is visible) and despite all of this, the graphic card still throws error 43.
Running latest driver at the time of writing, attempting to rollback to an earlier one right now hoping it might be some newly added defense of NVidia.
@sk1080 Do you have any idea what might be the issue here?
At this point with qemu/kvm, you should just hide the kvm syscalls, and optionally expose the hyper-v ones (they may not cause any real-world performance increase). What bios are you running? Using qemu's default seabios, I get code 43 regardless of what I do to the driver. I was only able to get passthrough working with OVMF.
@sk1080 As it turns out some Hypervisor / Host motherboards don't combine well with NVidia drivers inside a virtualized environment when using line-based interrupts.
The key to getting my NVidia graphic cards working (GTX760 and GTX1060) was to immediately switch them into message-signaled interrupt mode, right after installing the NVidia drivers (but before the obligatory post-driver-install system reboot).
Of course, this has to be combined with the two typical NVidia code 43 workarounds (hiding kvm, renaming cpu-id).
Here's a link to the tutorial on guru3d, explaining how to switch your graphic card (and hdmi soundcard) into message-signaled interrupt mode: http://forums.guru3d.com/showthread.php?t=378044
This might be worth mentioning on the readme.md file btw, as I've already encountered two mainboards that require this mod in addition to the usual 2 (both ASRock mainboards btw).
@MrColdbird thanks for the tip, I added it to the readme. Don't think I ever had to flip my graphics card on any of my test systems, but I certainly had to use that script for some other (virtualized) devices, so I may just have failed to notice.
@sk1080
I fail this requirement:
Access control services (ACS) on PCI Express root ports.
You should add -Force parameter
