Re: [PATCH] PCIUtils: a test case for the SR-IOV and ARI capabilities

["Zhao, Yu" <yu.zhao@xxxxxxxxx>]

Fischer, Anna wrote:
> > From: linux-pci-owner@xxxxxxxxxxxxxxx [mailto:linux-pci-
> > owner@xxxxxxxxxxxxxxx] On Behalf Of Yu Zhao
> > Sent: 16 December 2008 08:11
> > To: Martin Mares
> > Cc: Linux-PCI Mailing List
> > Subject: [PATCH] PCIUtils: a test case for the SR-IOV and ARI
> > capabilities
> >
> > 01:00.0 Ethernet controller: Intel Corporation Device 10c9 (rev 01)
> >         Subsystem: Intel Corporation Device a03c
> >         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 A routed to IRQ 16
> >         Region 0: Memory at e0800000 (32-bit, non-prefetchable)
> > [size=128K]
> >         Region 1: Memory at e0000000 (32-bit, non-prefetchable)
> > [size=4M]
> >         Region 2: I/O ports at 1020 [size=32]
> >         Region 3: Memory at e0840000 (32-bit, non-prefetchable)
> > [size=16K]
> >         Expansion ROM at c7800000 [disabled] [size=4M]
> >         Capabilities: [40] Power Management version 3
> >                 Flags: PMEClk- DSI+ D1- D2- AuxCurrent=0mA PME(D0+,D1-
> > ,D2-,D3hot+,D3cold+)
> >                 Status: D0 PME-Enable- DSel=0 DScale=1 PME-
> >         Capabilities: [50] MSI: Mask+ 64bit+ Count=1/1 Enable-
> >                 Address: 0000000000000000  Data: 0000
> >                 Masking: 00000000  Pending: 00000000
> >         Capabilities: [70] MSI-X: Enable+ Mask- TabSize=10
> >                 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 256 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- Suprise- LLActRep- BwNot-
> >                 LnkCtl: ASPM L1 Enabled; 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: 50us to 50ms, 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: [100] 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: [140] Device Serial Number e0-46-2b-ff-ff-21-1b-
> > 00
> >         Capabilities: [150] Alternative Routing-ID Interpretation (ARI)
> >                 ARICap: MFVC- ACS-, Next Function: 1
> >                 ARICtl: MFVC- ACS-, Function Group: 0
> >         Capabilities: [160] Single Root I/O Virtualization (SR-IOV)
> >                 IOVCap: Migration-, Interrupt Message Number: 000
> >                 IOVCtl: Enable+ Migration- Interrupt- MSE+
> > ARIHierarchy-
> >                 IOVSta: Migration-
> >                 Initial VFs: 8, Total VFs: 8, Number of VFs: 1,
> > Function Dependency Link: 00
> >                 VF offset: 384, stride: 2, Device ID: 10ca
> >                 Supported Page Size: 00000553, System Page Size:
> > 00000001
> >                 VF Migration: offset: 00000000, BIR: 0
> >         Kernel driver in use: igb
>
>
> [...]
>
> It would be great if the lspci command could also show VF memory configuration properly. For example, for my VFs, currently it shows
>
> a0:00.1
>         Flags: bus master, fast devsel, latency 0
>         [virtual] Memory at 160000000 (32-bit, non-prefetchable) [disabled] [size=512K]
>         [virtual] Memory at 140000000 (32-bit, non-prefetchable) [disabled] [size=8M]
>         Capabilities: [60] Express Endpoint, MSI 00
>         Capabilities: [9c] MSI-X: Enable- Mask- TabSize=3
>
> memory address values correctly, but bit length and flags are wrong because the VF BARs are read-only 0. It would be nice if it was detectable that this is a VF and to then get this information from the related PF? Showing this information wrongly might cause other tools to fail.

Yes, this is on my todo list. The libpci would read BAR flags from 
/sys/bus/pci/devices/.../resource and expose the flags in the 'pci_dev'. 
So applications (including lspci) built on libpci can detect use the 
correct flags for the virtual BARs.

> Obviously this assumes that VF and PF run in the same OS, and I am not sure how this would work when the VF runs in a VM where the PF is not accessible... But in that case you might want to "emulate" VF configuration space anyway, and shadow certain VF control registers, I guess. But this would be something that the virtualization layer has to do.
>
> Anna
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-pci" in
> the body of a message to majordomo@xxxxxxxxxxxxxxx
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

--
To unsubscribe from this list: send the line "unsubscribe linux-pci" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html