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>
To: john cooper <john.cooper>
CC: Bill Burns <bburns>, "Nakajima, Jun" <jun.nakajima>,
        "Yu, Wilfred" <wilfred.yu>
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 [john.cooper]
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.