Red Hat Bugzilla – Bug 613892
[SR-IOV]VF device can not start on 32bit Windows2008 SP2
Last modified: 2014-07-24 23:46:00 EDT
Description of problem: With RHEL6 Beta2, Kawela VF can be assigned to 32bit Windows 2008 SP2 with qemu-kvm cmdline, device manager show "yellow bang" and it's said "This device can not start. (Code 10)". VF device can not work on 32bit Windows 2k8 SP2. Version-Release number of selected component (if applicable): rhel6-beta2 2.6.32-37.el6.x86_64 How reproducible: Always Steps to Reproduce: 1. Install 32bit Windows 2008 SP2 and assign Kawela VF to it 2. Install driver from http://downloadcenter.intel.com/T8Clearance.aspx?sType=&agr=Y&ProductID=&DwnldID=18720&url=/18720/a08/PROWin32.exe&PrdMap=&strOSs=&OSFullName=&lang=eng 3. Reboot guest and check network connection Actual results: VF can not get IP Expected results: VF can work on Windows SP2. Additional info:
Created attachment 431354 [details] vf device can not start on guest
Please provide: -- host kernel version -- guest startup cmdline (if use qemu-kvm directly) or xml spec (if you virsh)
Created attachment 431573 [details] cannot find enough free resources I get a different error message, see the attached image. This same error happens both with current rhel6 bits and upstream kvm. Looking at the log files doesn't seem to suggest a PCI BAR resource issue. Can we get some help to understand what the driver is looking for that it can't find resources for?
When we debugged here there is no error in the driver that we can see. It seems like the OS is having some issues with getting resources required for the device (such as MSI-X.) The same driver is working correct on Xen Server so we are not certain what the difference is between the two systems that would cause this.
(In reply to comment #3) > -- host kernel version > kernel 2.6.32-37.el6.x86_64. qemu-kvm-0.12.1.2 > -- guest startup cmdline (if use qemu-kvm directly) or xml spec (if you virsh) qemu-kvm command line: /usr/libexec/qemu-kvm -m 1024 -smp 2 -net none -hda /var/lib/libvirt/images/win2k8.img -pcidevice host=01:10.0
Can you provide both an 'lspci -vvv' and an 'ls -l /sys/bus/pci/devices/0000:00:xx.y/' from a linux guest with the device assigned to it running on xenserver? Maybe we can spot something different in the features or config space they're exposing.
I've noticed that 32bit Windows on kvm typically does not use MSI interrupts. However, if I boot the guest with '-cpu host' MSI will be used and the 82576 VF works. Is Windows looking for specific processor flags to enable MSI interrupt support?
Looks like 32bit Windows doesn't enable MSI support until family 6, model 13 processor revisions, so if you boot using -cpu qemu64,model=13 the VF works as expected.
(In reply to comment #9) > Looks like 32bit Windows doesn't enable MSI support until family 6, model 13 > processor revisions, so if you boot using -cpu qemu64,model=13 the VF works as > expected. yeah, with the arg "-cpu qemu64,model=13", the VF can work well.
Can you retest with one of the following option (most suitable to the host): -cpu Penryn or Nehalem or Conroe? They should have family=6, model =15
(In reply to comment #11) > Can you retest with one of the following option (most suitable to the host): > -cpu Penryn or Nehalem or Conroe? They should have family=6, model =15 Oops, the AMD models have model=15 while the ones above have model 6. We should change that.
These fields inspire headaches. Currently for the new models we use the Intel and AMD reviewed values of: AMD Opteron_G1/G2/G3: family = "15" model = "6" Intel Conroe/Penryn/Nehalem + qemu64: family = "6" model = "2" So the Intel cpu model CPUID provided "model" fields and those of qemu64 require the prospective change. Awaiting input from Intel on this.
(In reply to comment #11) > Can you retest with one of the following option (most suitable to the host): > -cpu Penryn or Nehalem or Conroe? They should have family=6, model =15 I have retest with those args. Unfortunately, VF can not work with it.
Feedback form Intel (mail attached for reference). The recommendation summary for cpuid "model" is: Conroe: 15 Penryn: 23 Nehalem: 26 Concerning qemu64, empirically the model value needs to be at least 13, with a rhel5-equivalent legacy model added for compatibility.
From: "Dugger, Donald D" <donald.d.dugger@intel.com> To: john cooper <john.cooper@redhat.com> CC: Bill Burns <bburns@redhat.com>, "Nakajima, Jun" <jun.nakajima@intel.com>, "Yu, Wilfred" <wilfred.yu@intel.com> Date: Mon, 26 Jul 2010 18:43:33 -0700 Subject: RE: Need Intel input on CPUID model.. John- Yeah, this whole issue of virtualizing the family/model (which we have to do) and how it exposes unexpected issues is pretty icky (note, I would contend that the Windows code is wrong, there's no relationship between MSI support and the CPU model but the reality is we have to get the Windows guest to work). We talked this issue over in our team meeting today and the bottom line is that using Family 6, Model 13 when identifying a virtual CPU with either Conroe or Penryn or Nehalem capabilities should work just fine. Those 3 CPUs all have model numbers greater than 13 (Conroe = 15, Penryn = 23, Nehalem = 26) so 13 will certainly work as a least common denominator for them. -- Don Dugger "Censeo Toto nos in Kansa esse decisse." - D. Gale Ph: 303/443-3786 -----Original Message----- From: john cooper [mailto:john.cooper@redhat.com] Sent: Monday, July 26, 2010 1:10 PM To: Dugger, Donald D Cc: john cooper; Bill Burns Subject: Need Intel input on CPUID model.. Don, We have a bug with SR-IOV where the CPUID family:model must be at least 6:13 for a 32bit windows guest to enable MSI. So we're considering to make such a change for the new Conroe/Penryn/Nehalem models we've discussed with you folks. However currently we're using 6:2 for family:model as advised by Intel for a least-common-denominator in the respective classes. As such we're a bit hesitant to make a change without feedback either way from you.
Remove the NeedInfo request for xudong.
Verified this bug with rhel6 snap10, and PASSED. libvirt-0.8.1-21.el6.x86_64 qemu-kvm-tools-0.12.1.2-2.108.el6.x86_64 qemu-kvm-0.12.1.2-2.108.el6.x86_64 kernel-2.6.32-59.el6.x86_64
(In reply to comment #22) > Verified this bug with rhel6 snap10, and PASSED. > > libvirt-0.8.1-21.el6.x86_64 > qemu-kvm-tools-0.12.1.2-2.108.el6.x86_64 > qemu-kvm-0.12.1.2-2.108.el6.x86_64 > kernel-2.6.32-59.el6.x86_64
Red Hat Enterprise Linux 6.0 is now available and should resolve the problem described in this bug report. This report is therefore being closed with a resolution of CURRENTRELEASE. You may reopen this bug report if the solution does not work for you.