sk1080 / nvidia-kvm-patcher

Fixes "Bug" in Nvidia Driver preventing "Unsupported Configurations" from being used on KVM
314 stars 53 forks source link

Automatic Repair #1

Open ghost opened 7 years ago

ghost commented 7 years ago

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

sk1080 commented 7 years ago

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

ghost commented 7 years ago

No blue screen unfortunately, just rebooting after driver installation completes and no joy.

ghost commented 7 years ago

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.

image

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.

sk1080 commented 7 years ago

Did you enable test signing? I don't see the watermark, but your window could be covering it.

ghost commented 7 years ago

Haha, sorry. Yes, test signing is enabled.

sk1080 commented 7 years ago

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.

ghost commented 7 years ago

testsigning off does boot. Still getting code 52.

sk1080 commented 7 years ago

Could you take a screenshot of the driver tab under the properties for your graphics card?

ghost commented 7 years ago

Changed executionpolicy to "Bypass" just for the purpose of this, but here you go: output.txt

Screenshot coming up.

ghost commented 7 years ago

testsigning still off - not sure if that affects the Digital Signer portion...

capture

Edit: testsigning on - Not digitally signed

sk1080 commented 7 years ago

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.

ghost commented 7 years ago

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.

sk1080 commented 7 years ago

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.

ghost commented 7 years ago

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

sk1080 commented 7 years ago

And still fails?

ghost commented 7 years ago

Well that's pretty definitive. Back to Automatic Startup Repair.

sk1080 commented 7 years ago

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.

ghost commented 7 years ago

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!

ghost commented 7 years ago

Here's a bootlog for you, maybe you can see something in there that makes sense to you!

ntbtlog.txt

sk1080 commented 7 years ago

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.

ghost commented 7 years ago

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/

sk1080 commented 7 years ago

I fail this requirement: Access control services (ACS) on PCI Express root ports.

ghost commented 7 years ago

Sorry for the slow reply- was away for work.

That's unfortunate to hear but thanks for giving it a shot anyway.

sk1080 commented 7 years ago

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.

MrColdbird commented 7 years ago

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?

sk1080 commented 7 years ago

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.

MrColdbird commented 7 years ago

@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).

sk1080 commented 7 years ago

@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.

ChasonTang commented 7 years ago

@sk1080

I fail this requirement:
Access control services (ACS) on PCI Express root ports.

You should add -Force parameter