Thanx for using Intel Ethernet.
While I am no longer the TME responsible for virtualization, I'll jump in and see if I can lend a hand.
How many VF's did you try to instantiate with the 82599?
The usual reason for this message is that the BIOS did not properly allocate sufficient MMIO space for all of the potentila VFs. You might try updating your BIOS.
If you look at the following blog:
It will take you to my SR-IOV Primer and you can get the details in there of what and how the BIOS is supposed to calculate the MMIO space.
You can also try creating less VF's (max_vfs=5) say for the driver parameter, and see what happens.
Looking forward to seeing your response.
I just create 4 vfs. Even if I only just create 1, it fails. And the probelm is just the same as https://bugzilla.redhat.com/show_bug.cgi?id=523341. I have already get the vfs of 82576( gigabit ethernet ) , however when I just do the same things for 82599 ( gigabit ethernet ), it fails. I will try to update the BIOS. And I will read the document you recommended carefully!
Thanks a lot!
we have traced the path of resource allcating,then we find the first time the pcibios allocate resource failed for the bus which containing the 82599,after this,we can see no proper resource availabe in the bus. In this case, we let the linux kernel do the work that bios should do. However, when we get the BIOS to allocate resources, it still get a problem of resource allocation failed (we have update the BIOS to the latest virsion).
Might it be that the kernel get a bug? We would go on reading the pci part of linux kernel. Could it be a solution ?
Ok, I recalled some details and looked again at my system.
First, I had to turn two options in BIOS (on my supermicro board): one was for VT-d, the other was to explicitely enable SRIOV. Check it out in PCI section of you BIOS, and probably it's a good idea to walk through BIOS setting s with BIOS manual from the manufacturer.
The other things is : run
lspci -vv -s $pci_id
and check if it references SR-IOV capabilities, like my X520Capabilities:  Single Root I/O Virtualization (SR-IOV)IOVCap: Migration-, Interrupt Message Number: 000IOVCtl: Enable+ Migration- Interrupt- MSE+ ARIHierarchy+IOVSta: Migration-Initial VFs: 64, Total VFs: 64, Number of VFs: 7, Function Dependency Link: 00VF offset: 128, stride: 2, Device ID: 10edSupported Page Size: 00000553, System Page Size: 00000001Region 0: Memory at 00000000fa800000 (64-bit, non-prefetchable)Region 3: Memory at 00000000fa900000 (64-bit, non-prefetchable)VF Migration: offset: 00000000, BIR: 0
So it's important that "Region" memories were not at 0
Another things is that MSI-X is enabled (also checked in the output of lspci), and yet another thing to look for is ARI capabiliti and hierarhy support.
Also, just try a different PCI-e slot, and try to get other cards out and have X520 alone.
I have a similar setup (Centos 6.0, Supermicro MB, 82576 NIC) but only the Linux guests work properly with the 82576 VF. The Windows ones (both 2008R2 and 7 x64) see an Ethernet Controller but the intel driver does not detect them. I am using KVM.
Is there anything in your setup that configures the NICs in a particular way?
Is there any particular configuration required in the VMs xml file?
This is the output of lspci:
sudo lspci -vv -s 04:00.1
04:00.1 Ethernet controller: Intel Corporation 82576 Gigabit Network Connection (rev 01)
Subsystem: Intel Corporation Gigabit ET Dual Port Server Adapter
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B- DisINTx+
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
Latency: 0, Cache Line Size: 64 bytes
Interrupt: pin B routed to IRQ 17
Region 0: Memory at fdfe0000 (32-bit, non-prefetchable) [size=128K]
Region 2: I/O ports at d800 [size=32]
Region 3: Memory at fdfdc000 (32-bit, non-prefetchable) [size=16K]
Expansion ROM at fe000000 [disabled] [size=4M]
Capabilities:  Power Management version 3
Flags: PMEClk- DSI+ D1- D2- AuxCurrent=0mA PME(D0+,D1-,D2-,D3hot+,D3cold+)
Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=1 PME-
Capabilities:  MSI: Enable- Count=1/1 Maskable+ 64bit+
Address: 0000000000000000 Data: 0000
Masking: 00000000 Pending: 00000000
Capabilities:  MSI-X: Enable+ Count=10 Masked-
Vector table: BAR=3 offset=00000000
PBA: BAR=3 offset=00002000
Capabilities: [a0] Express (v2) Endpoint, MSI 00
DevCap: MaxPayload 512 bytes, PhantFunc 0, Latency L0s <512ns, L1 <64us
ExtTag- AttnBtn- AttnInd- PwrInd- RBE+ FLReset+
DevCtl: Report errors: Correctable+ Non-Fatal+ Fatal+ Unsupported+
RlxdOrd- ExtTag- PhantFunc- AuxPwr- NoSnoop+ FLReset-
MaxPayload 128 bytes, MaxReadReq 512 bytes
DevSta: CorrErr+ UncorrErr- FatalErr- UnsuppReq+ AuxPwr+ TransPend-
LnkCap: Port #0, Speed 2.5GT/s, Width x4, ASPM L0s L1, Latency L0 <4us, L1 <64us
ClockPM- Surprise- LLActRep- BwNot-
LnkCtl: ASPM Disabled; RCB 64 bytes Disabled- Retrain- CommClk+
ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt-
LnkSta: Speed 2.5GT/s, Width x4, TrErr- Train- SlotClk+ DLActive- BWMgmt- ABWMgmt-
DevCap2: Completion Timeout: Range ABCD, TimeoutDis+
DevCtl2: Completion Timeout: 16ms to 55ms, TimeoutDis-
LnkCtl2: Target Link Speed: 2.5GT/s, EnterCompliance- SpeedDis-, Selectable De-emphasis: -6dB
Transmit Margin: Normal Operating Range, EnterModifiedCompliance- ComplianceSOS-
Compliance De-emphasis: -6dB
LnkSta2: Current De-emphasis Level: -6dB
Capabilities:  Advanced Error Reporting
UESta: DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt- RxOF- MalfTLP- ECRC- UnsupReq- ACSViol-
UEMsk: DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt- RxOF- MalfTLP- ECRC- UnsupReq- ACSViol-
UESvrt: DLP+ SDES- TLP- FCP+ CmpltTO- CmpltAbrt- UnxCmplt- RxOF+ MalfTLP+ ECRC- UnsupReq- ACSViol-
CESta: RxErr- BadTLP- BadDLLP- Rollover- Timeout- NonFatalErr+
CEMsk: RxErr- BadTLP- BadDLLP- Rollover- Timeout- NonFatalErr+
AERCap: First Error Pointer: 00, GenCap- CGenEn- ChkCap- ChkEn-
Capabilities:  Device Serial Number 00-1b-21-ff-ff-a1-04-f2
Capabilities:  Alternative Routing-ID Interpretation (ARI)
ARICap: MFVC- ACS-, Next Function: 0
ARICtl: MFVC- ACS-, Function Group: 0
Capabilities:  Single Root I/O Virtualization (SR-IOV)
IOVCap: Migration-, Interrupt Message Number: 000
IOVCtl: Enable+ Migration- Interrupt- MSE+ ARIHierarchy-
Initial VFs: 8, Total VFs: 8, Number of VFs: 7, Function Dependency Link: 01
VF offset: 128, stride: 2, Device ID: 10ca
Supported Page Size: 00000553, System Page Size: 00000001
Region 0: Memory at 00000000fd340000 (64-bit, non-prefetchable)
Region 3: Memory at 00000000fd360000 (64-bit, non-prefetchable)
VF Migration: offset: 00000000, BIR: 0
Kernel driver in use: igb
Kernel modules: igb
Thank you very much for your help
Message was edited by: chbarg (changed font size)
I did some resarch on the Fedora Project site. Fedora 15 uses a renamed 3.1 kernel aka 2.6.41.x kernel. See https://fedoraproject.org/wiki/Kernel for details. That kernel has support for SR-IOV, so your OS should work. I am not sure what drivers are included in the distribution package, but you can always get the latest PF and VF drivers from http://downloadcenter.intel.com.
Unfortunately, the lack of any BIOS settings for SR-IOV makes me think that your server hardware (or the BIOS) does not support SR-IOV. You need BIOS and hardware support on the platform. You should probably check with ASUS about SR-IOV support.
I just downloaded the Intel PROWinx64.exe V17 dated 03/23/2012 that should include support for VF under Win 2008 R2 from:
From inside guest VM I can see the NIC with missing drivers. Win 2008 R2 reports the correct hardware ID:
Are these the correct hardware IDs for the 82576 VF?
Linux guests work perfectly using the VF so I assume that the MB and Bios correctly supports SR-IOV.
Thank you very much for your help
MB = SuperMicro H8SCM BIOS V 2.0
CPU = Opteron 4180 or Opteron 4226
OS = Centos 6.2 x64 with all updates
Guest OS = Win 2008 R2