How about Xenserver and Windows 7

[evolutiontofuture]

Hi, I have test the patch on Windows 7 64 bit running on Xen, still got error 43. Does the Windows version or KVM/Xen make the different? How can i debug and trace to fix it on Windows 7 on Xen?

[evolutiontofuture]

I'm sure the patch had been applied. Without patch, the VM BSOD.

[evolutiontofuture]

I have tested the patch on Windows 10 on Xen today, still no luck. :( It seems Xenserver is strange than KVM, even change CPUID never help. Can you tell me how to debug and trace it?

[evolutiontofuture]

Error code : 43.

[evolutiontofuture]

driver versions tryed: 372.54 and 368.39

[sk1080]

Original debugging was done with windbg, with breakpoints on known instances of the cpuid instruction within the nvidia driver. I wouldn't be surprised if other virtualization platforms trigger things a bit differently. Other things to look for include MSR reads (rdmsr) and other uses of cpuid that I didn't nerf, but would indicate virtualization. If I get the time, ill see if I can get a test instance of xen going.

[evolutiontofuture]

By search cpuid instruction in assembly in IDA pro, i can only found one in the driver. Then i try to instrument the CPUID: which from : db 0fh, 0a2h ;;; cpuid db 48h, 8bh, 7ch, 24h, 30h ;;; mov rdi, [rsp+30h] db 89h, 07h ;;; mov [rdi], eax db 48h, 8Bh, 7Ch, 24h, 38h ;;; mov rdi, [rsp+38h] db 89h, 1fh ;;; mov [rdi], ebx db 48h, 8Bh, 7Ch, 24h, 40h ;;; mov rdi, [rsp+40h] db 89h, 0fh ;;; mov [rdi], ecx db 48h, 8Bh, 7Ch, 24h, 48h ;;; mov rdi, [rsp+48h] db 89h, 17h ;;; mov [rdi], edx db 48h, 0c7h, 0c0h, 01h, 0h, 0h, 0h ;;; mov rax, 1 db 48h, 83h, 0c4h, 00h ;;; add rsp, 0 db 5fh ;;; pop rdi db 5bh ;;; pop rbx db 0c3h ;;; retn

to

cmp     eax, 0h
jne     not_for_vender_id

cpuid
;mov        ebx, 756e6547h          ;;GenuineIntel
;mov        ecx, 6c65746eh
;mov        edx, 49656e69h
mov     ebx, 4b4d564bh          ;;KVMK
mov     edx, 564d4b56h          ;;VMKV
mov     ecx, 4d4b564dh          ;;MKVM
jmp     return_back
nop
nop
nop

not_for_vender_id: cmp eax, 1h je detect_hypervisor_bit cpuid

return_back: mov rdi, [rsp+30h] mov [rdi], eax mov rdi, [rsp+38h] mov [rdi], ebx mov rdi, [rsp+40h] mov [rdi], ecx mov rdi, [rsp+48h] mov [rdi], edx mov rax, 1 add rsp, 0 pop rdi pop rbx ret

detect_hypervisor_bit: cpuid and ecx, 7fffffffh jmp return_back

try to fill "GenuineIntel" or "KVMKVMKVMKVM" with no lucky.

Do you have any suggestions?

[sk1080]

Probably isn't vendor ID that is tripping it with my patch in place, especially as I verified mine is currently set as "Microsoft Hv", which they blacklist. If I get to it, ill see what else might be causing it to error out.

[sk1080]

Haven't given windows 7 a test, but I did have a go with Windows 10, xen 4.7 (not xenserver...), and driver 373.06, which seems to work for me (driver doesn't error out, is displaying windows desktop, 3d untested). I don't know how xenserver sets things up(never used it before), but I assume it runs a rather unmodified xen hypervisor? This is a fresh build of the xen hypervisor running on a pure efi host, with my normal desktop setup as dom0. Obvious downside of this setup is that I don't think xen is capable of making the passed-through graphics card the primary card for the vm.

Windows 10 install was completely fresh(from iso). Nvidia driver/wdk download/patcher download and application/testmode enabling were the only tasks performed post-install.

builder='hvm'
memory = 4096
name = 'win10'
vcpus=8
pae=1
acpi=1
apic=1
on_xend_stop='shutdown'
vif = [ 'mac=00:16:3e:68:e1:01,type=ioemu,bridge=br0' ]
disk = [ '/srv/xen/win10.img,,hda' , '/tmp/win10.iso,raw,hdd,cdrom' ]
device_model_version = 'qemu-xen-traditional'
boot='dc'
sdl=1
vnc=0
vncpasswd=''
serial='pty'
tsc_mode="default"
viridian=1
usb=1
usbdevice='tablet'
localtime=1
xen_platform_pci=1
pci_power_mgmt=1
gfx_passthru=0
pci=[ '04:00.0', '04:00.1' ]
#device_model_version='qemu-xen'
#bios='ovmf'

[evolutiontofuture]

That's great! Maybe Xenserver has some modification. I'll try it 373.06 and xenserver 7.0 later.

2016-10-11 11:33 GMT+08:00, sk1080 notifications@github.com:

Haven't given windows 7 a test, but I did have a go with Windows 10, xen 4.7 (not xenserver...), and driver 373.06, which seems to work for me (driver doesn't error out, is displaying windows desktop, 3d untested). I don't know how xenserver sets things up(never used it before), but I assume it runs a rather unmodified xen hypervisor? This is a fresh build of the xen hypervisor running on a pure efi host, with my normal desktop setup as dom0. Obvious downside of this setup is that I don't think xen is capable of making the passed-through graphics card the primary card for the vm.

Windows 10 install was completely fresh(from iso). Nvidia driver/wdk download/patcher download and application/testmode enabling were the only tasks performed post-install.

builder='hvm'
memory = 4096
name = 'win10'
vcpus=8
pae=1
acpi=1
apic=1
on_xend_stop='shutdown'
vif = [ 'mac=00:16:3e:68:e1:01,type=ioemu,bridge=br0' ]
disk = [ '/srv/xen/win10.img,,hda' , '/tmp/win10.iso,raw,hdd,cdrom' ]
device_model_version = 'qemu-xen-traditional'
boot='dc'
sdl=1
vnc=0
vncpasswd=''
serial='pty'
tsc_mode="default"
viridian=1
usb=1
usbdevice='tablet'
localtime=1
xen_platform_pci=1
pci_power_mgmt=1
gfx_passthru=0
pci=[ '04:00.0', '04:00.1' ]
#device_model_version='qemu-xen'
#bios='ovmf'

You are receiving this because you authored the thread. Reply to this email directly or view it on GitHub: https://github.com/sk1080/nvidia-kvm-patcher/issues/4#issuecomment-252802876

[sk1080]

I just added Windows 7 x64 Support to the repo. Also, code 43 seems to happen for reasons unrelated to the hypervisor detection, and can be dependent on the bios used by the virtualization platform. I was unable to get things to work on Windows 7 on qemu's bios, but things worked with OVMF. When I tested xen, I only tested its bios, which worked, and not ovmf, so I can't speak for that situation.

[sshaikh]

@evolutiontofuture did you manage to get this working?

[sk1080]

I don't know if he did, but I "did". However, got horrible graphics corruption and issues, although the card did "work". libvirt/qemu is probably a better idea.

[evolutiontofuture]

Not yet. :(

2017-04-14 0:49 GMT+08:00, sshaikh notifications@github.com:

@evolutiontofuture did you manage to get this working?

-- You are receiving this because you were mentioned. Reply to this email directly or view it on GitHub: https://github.com/sk1080/nvidia-kvm-patcher/issues/4#issuecomment-293958023

[sshaikh]

I've posted on another issue but here it is again:

"Good call wrt KVM. I spent a couple of hours setting up the passing through of the card to a Proxmox VM and it works perfectly, with no hacking on the guest. Recommended for those who have the option."

[imtrobin]

Is this supposed to be working on xen? I patch it fine without errors, when I install, it says Nvidia driver failed,

still code 43, the event log shows

Device PCI\VEN_10DE&DEV_1B81&SUBSYS_143519DA&REV_A1\3&267a616a&0&38 requires further installation.

Driver Management has concluded the process to add Service nvlddmkm for Device Instance ID PCI\VEN_10DE&DEV_1B81&SUBSYS_143519DA&REV_A1\3&267A616A&0&38 with the following status: 0.

Driver 436.48