Bug 1273172

Win7 also reports Code 12 if the GPU is attached to the pci.2 bus, which is currently the default for any libvirt attached device.  Moving the GPU to pcie.0 by changing bus to 0x00 in the XML allows the device to work, however note that we don't support hotplug on pcie.0.  Perhaps the default configuration is how we can report this to NVIDIA.

[Also note that in the configuration listed in comment 0, a Teradici card is also placed behind a separate PCIe root port in the VM, this device reports no driver issues]

Reported to NVIDIA:

https://partners.nvidia.com/bug/viewbug/1696961

Since Windows 7 appears to get a Code 12 any time the GPU is behind a PCI-bridge, I reported the case of a 440FX VM configured with a pci-bridge and the GPU attached to the secondary bus.

Hi Alex,

Can you take the following steps:

1 Set SetupApi LogLevel to -1 (0xffffffff) (https://msdn.microsoft.com/en-us/library/windows/hardware/ff550808%28v=vs.85%29.aspx)
2. Reboot the VM.
3. Try to install NVIDIA driver and share the setupapi installation log (https://msdn.microsoft.com/en-us/library/windows/hardware/ff550863%28v=vs.85%29.aspx)

Thanks,
Vadim.

It's ok Lijin and Amnon.

Hi Zhiyi,

Could you handle this issue?

Best Regards,
Junyi

Created attachment 1106717 [details]
win7-64 hckx log

the PNP job all failed at setup stage with error "WDTF_TEST : Found a device that has a non-zero problem code or is phantom. Logging device info."

the PCI hardware compliance test failed due to error "Assertion 1587DC0B-FE59-494E-85B5-C2A59D0CC098: FAILED. Bit 6 (Common Clock Configuration) in the Link Control register (offset 10h) in the PCI Express Capability table must be read-writable ."

please check the hckx log for details

(In reply to lijin from comment #17)
> Created attachment 1106717 [details]
> win7-64 hckx log
> 
> the PNP job all failed at setup stage with error "WDTF_TEST : Found a device
> that has a non-zero problem code or is phantom. Logging device info."
> 
> the PCI hardware compliance test failed due to error "Assertion
> 1587DC0B-FE59-494E-85B5-C2A59D0CC098: FAILED. Bit 6 (Common Clock
> Configuration) in the Link Control register (offset 10h) in the PCI Express
> Capability table must be read-writable ."
> 
> please check the hckx log for details

Hi, Lijin

Yes, according to the PCI hardware compliance test there are three problematic bits - 6,7,and 8 which all must be RW. Apart from that there are a bunch of PnP tests that failed due to Configuration Manager probe conflict. 
I wonder if we can run the same set of tests on a different configuration, where the NVIDIA board located on the primary PCI bus?
And it also will be helpful to know if the same problem can be reproduced on a "legacy" i440-based system.

Thanks,
Vadim.

(In reply to Vadim Rozenfeld from comment #18)
> (In reply to lijin from comment #17)
> > Created attachment 1106717 [details]
> > win7-64 hckx log
> > 
> > the PNP job all failed at setup stage with error "WDTF_TEST : Found a device
> > that has a non-zero problem code or is phantom. Logging device info."
> > 
> > the PCI hardware compliance test failed due to error "Assertion
> > 1587DC0B-FE59-494E-85B5-C2A59D0CC098: FAILED. Bit 6 (Common Clock
> > Configuration) in the Link Control register (offset 10h) in the PCI Express
> > Capability table must be read-writable ."
> > 
> > please check the hckx log for details
> 
> Hi, Lijin
> 
> Yes, according to the PCI hardware compliance test there are three
> problematic bits - 6,7,and 8 which all must be RW. Apart from that there are
> a bunch of PnP tests that failed due to Configuration Manager probe
> conflict. 
> I wonder if we can run the same set of tests on a different configuration,
> where the NVIDIA board located on the primary PCI bus?
> And it also will be helpful to know if the same problem can be reproduced on
> a "legacy" i440-based system.

QE will update the result once finish.

Hi zhguo,is the env. in comment#11 still available?

Created attachment 1128483 [details]
win7_64_q35_nvidia_GPU whql log

reproduce on q35 system:
the PNP job all failed with error "WDTF_TEST: Found a device that has a non-zero problem code or is phantom. Logging device info."

the PCI hardware compilance test passed.

reproduced on i440 system:
passthrough NVIDIA K5000 to guest success, but after update the GPU driver, reboot the guest, guest os will hung in 'Starting Windows' page, tried 4 times, results are same.


use virt-manager boot a i440 system, command as follows:
/usr/libexec/qemu-kvm -name win7-2 -machine pc-i440fx-rhel7.2.0,accel=kvm,usb=off,vmport=off -cpu SandyBridge,hv_time,hv_relaxed,hv_vapic,hv_spinlocks=0x1fff -m 4096 -realtime mlock=off -smp 8,sockets=2,cores=4,threads=1 -uuid d518b1aa-f1e4-41fe-bf9c-98c0489504fb -qmp tcp::4444,server,nowait -rtc base=localtime,driftfix=slew -global kvm-pit.lost_tick_policy=discard -no-hpet -no-shutdown -global PIIX4_PM.disable_s3=1 -global PIIX4_PM.disable_s4=1 -boot strict=on -vga cirrus -device virtio-serial-pci,id=virtio-serial0,bus=pci.0,addr=0x5 -drive file=test.qcow2,if=none,id=drive-ide0-0-0,format=qcow2 -device ide-hd,bus=ide.0,unit=0,drive=drive-ide0-0-0,id=ide0-0-0,bootindex=1 -drive file=en_windows_7_ultimate_x64_dvd_x15-65922.iso,if=none,id=drive-ide0-0-1,readonly=on,format=raw -device ide-cd,bus=ide.0,unit=1,drive=drive-ide0-0-1,id=ide0-0-1,bootindex=0 -netdev tap,id=hostnet0 -device rtl8139,netdev=hostnet0,id=net0,mac=52:54:00:01:a8:eb,bus=pci.0,addr=0x3 -chardev pty,id=charserial0 -vnc 0.0.0.0:2
qemu     17427 14.9 17.9 5367728 4394944 ?     SLl  11:11  36:39 /usr/libexec/qemu-kvm -name win7 -S -machine pc-i440fx-rhel7.2.0,accel=kvm,usb=off,vmport=off -cpu SandyBridge,hv_time,hv_relaxed,hv_vapic,hv_spinlocks=0x1fff -m 4096 -realtime mlock=off -smp 8,sockets=8,cores=1,threads=1 -uuid d83fc7f7-cb55-4b87-a40b-e86243a78ed8 -no-user-config -nodefaults -chardev socket,id=charmonitor,path=/var/lib/libvirt/qemu/domain-win7/monitor.sock,server,nowait -mon chardev=charmonitor,id=monitor,mode=control -rtc base=localtime,driftfix=slew -global kvm-pit.lost_tick_policy=discard -no-hpet -no-shutdown -global PIIX4_PM.disable_s3=1 -global PIIX4_PM.disable_s4=1 -boot strict=on -device ich9-usb-ehci1,id=usb,bus=pci.0,addr=0x6.0x7 -device ich9-usb-uhci1,masterbus=usb.0,firstport=0,bus=pci.0,multifunction=on,addr=0x6 -device ich9-usb-uhci2,masterbus=usb.0,firstport=2,bus=pci.0,addr=0x6.0x1 -device ich9-usb-uhci3,masterbus=usb.0,firstport=4,bus=pci.0,addr=0x6.0x2 -device virtio-serial-pci,id=virtio-serial0,bus=pci.0,addr=0x5 -drive file=/home/peixiu_handle_bug/i440.qcow2,if=none,id=drive-ide0-0-0,format=qcow2 -device ide-hd,bus=ide.0,unit=0,drive=drive-ide0-0-0,id=ide0-0-0,bootindex=1 -drive file=/home/peixiu_handle_bug/en_windows_7_ultimate_x64_dvd_x15-65922.iso,if=none,id=drive-ide0-0-1,readonly=on,format=raw -device ide-cd,bus=ide.0,unit=1,drive=drive-ide0-0-1,id=ide0-0-1 -netdev tap,fd=23,id=hostnet0 -device rtl8139,netdev=hostnet0,id=net0,mac=52:54:00:19:2f:ef,bus=pci.0,addr=0x3 -chardev pty,id=charserial0 -device isa-serial,chardev=charserial0,id=serial0 -chardev spicevmc,id=charchannel0,name=vdagent -device virtserialport,bus=virtio-serial0.0,nr=1,chardev=charchannel0,id=channel0,name=com.redhat.spice.0 -device usb-tablet,id=input0 -spice port=5900,addr=127.0.0.1,disable-ticketing,image-compression=off,seamless-migration=on -device qxl-vga,id=video0,ram_size=67108864,vram_size=67108864,vgamem_mb=16,bus=pci.0,addr=0x2 -device intel-hda,id=sound0,bus=pci.0,addr=0x4 -device hda-duplex,id=sound0-codec0,bus=sound0.0,cad=0 -chardev spicevmc,id=charredir0,name=usbredir -device usb-redir,chardev=charredir0,id=redir0 -chardev spicevmc,id=charredir1,name=usbredir -device usb-redir,chardev=charredir1,id=redir1 -device vfio-pci,host=04:00.0,id=hostdev0,bus=pci.0,addr=0x8 -device vfio-pci,host=04:00.1,id=hostdev1,bus=pci.0,addr=0x9 -device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x7 -msg timestamp=on

Best Regards!
Peixiu Hou

Vadim,

it seems the problem is not Nvidia-dependent. I observe the same 'code 12' error with Win7 and ATI Radeon R9 290 adapter with both 440 and q35 chipsets while the adapter is connected to RC or bridge or pcie-root-port as soon as QXL VGA adapter is present. When I remove QXL adapter then the Radeon driver starts just fine. 

I am using latest F20 kernel on the host, libvirt 1.2.21 (recompiled virtpreview package myself for F20) and qemu-2.1.2-7.

Please let me know if you need any specific details.

(In reply to Sergey from comment #22)
> Vadim,
> 
> it seems the problem is not Nvidia-dependent. I observe the same 'code 12'
> error with Win7 and ATI Radeon R9 290 adapter with both 440 and q35 chipsets
> while the adapter is connected to RC or bridge or pcie-root-port as soon as
> QXL VGA adapter is present. When I remove QXL adapter then the Radeon driver
> starts just fine. 
> 
> I am using latest F20 kernel on the host, libvirt 1.2.21 (recompiled
> virtpreview package myself for F20) and qemu-2.1.2-7.
> 
> Please let me know if you need any specific details.

Hi Sergey,

We are still investigating this issue.
It might be related to the resource allocation mechanism,
at least we are observing some weird problems when running
WHQL PnP related tests on viostor driver sitting behind 
pci-to-pci bridge, and never if virtio-blk device attached
to the primary pci bus.

Best regards,
Vadim.

(In reply to Vadim Rozenfeld from comment #23)
> 
> Hi Sergey,
> 
> We are still investigating this issue.
> It might be related to the resource allocation mechanism,
> at least we are observing some weird problems when running
> WHQL PnP related tests on viostor driver sitting behind 
> pci-to-pci bridge, and never if virtio-blk device attached
> to the primary pci bus.
> 
> Best regards,
> Vadim.

Vadim, 

yesterday I gave up to force the Win7 to do what I need. Then I first tried the Win8.1, but for some reason the Windows setup did not recognize any disk drives in no configurations (IDE/VirtIO/SCSI and I supplied the drivers where appropriate). Finally I succeeded to setup Win10 and got Radeon _and_ QXL adapters working simultaneously. Just simple setting up of a VM using virt-manager and later addition of the host PCI device without any extra tricks (except Radeon Catalyst driver installation) works as expected: both devices are functional.

Kind regards,
Sergey.

QEMU has been recently split into sub-components and as a one-time operation to avoid breakage of tools, we are setting the QEMU sub-component of this BZ to "General". Please review and change the sub-component if necessary the next time you review this BZ. Thanks

After evaluating this issue, there are no plans to address it further or fix it in an upcoming release.  Therefore, it is being closed.  If plans change such that this issue will be fixed in an upcoming release, then the bug can be reopened.

Win7 VM is already EOL.
This issue is not reproducible with Win10 VM and latest qemu qemu-kvm-5.1.0 anymore.