From: Ben Hutchings <bhutchings@solarflare.com>
To: Ajit.Khaparde@Emulex.Com
Cc: netdev@vger.kernel.org
Subject: RE: [PATCH net-next 2/5] be2net: use common method to check for sriov function type
Date: Thu, 07 Apr 2011 14:37:39 +0100 [thread overview]
Message-ID: <1302183459.2878.7.camel@bwh-desktop> (raw)
In-Reply-To: <49395329523DD64492581B505F80C86D5A5BCD3946@EXMAIL.ad.emulex.com>
On Thu, 2011-04-07 at 05:34 -0700, Ajit.Khaparde@Emulex.Com wrote:
> ________________________________________
> > From: Ben Hutchings [bhutchings@solarflare.com]
> > Sent: Thursday, April 07, 2011 3:14 AM
> > To: Khaparde, Ajit
> > Cc: netdev@vger.kernel.org
> > Subject: Re: [PATCH net-next 2/5] be2net: use common method to check for sriov function type
>
> > On Wed, 2011-04-06 at 23:08 -0500, Ajit Khaparde wrote:
> >> Lancer and BE can both use SLI_INTF_REG to check a VF or a PF.
> > [...]
>
> > This seems pretty unreliable (both in the previous and the current
> > version). You cannot rely on the whole of PCI config space being mapped
> > to a VM guest. KVM certainly didn't do this when I used PCI pass-
> > through.
>
> That's interesting. I have been using the new method for a while now.
> And the older one has worked pretty well for a long time.
> Can you give some details about the adapter used?
> Let's start with the firmware version, lspci output.
I've tried this with PFs on Solarflare adapters.
This is how the PF looks in the KVM host:
# lspci -vv -xxx -s 06:00.1
06:00.1 Ethernet controller: Solarflare Communications SFC9020 [Solarstorm]
Subsystem: Solarflare Communications SFN5122F-R5
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR-
Latency: 0, Cache Line Size: 32 bytes
Interrupt: pin B routed to IRQ 95
Region 0: I/O ports at 2400 [size=256]
Region 2: Memory at dd000000 (64-bit, non-prefetchable) [size=16M]
Region 4: Memory at de010000 (64-bit, non-prefetchable) [size=64K]
Expansion ROM at de420000 [size=128K]
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=0 PME-
Capabilities: [50] Message Signalled Interrupts: 64bit+ Queue=0/5 Enable+
Address: 00000000fee0f00c Data: 41d6
Capabilities: [70] Express Endpoint IRQ 0
Device: Supported: MaxPayload 256 bytes, PhantFunc 0, ExtTag-
Device: Latency L0s <64ns, L1 <8us
Device: AtnBtn- AtnInd- PwrInd-
Device: Errors: Correctable- Non-Fatal- Fatal- Unsupported-
Device: RlxdOrd+ ExtTag- PhantFunc- AuxPwr- NoSnoop-
Device: MaxPayload 256 bytes, MaxReadReq 512 bytes
Link: Supported Speed unknown, Width x8, ASPM L0s L1, Port 0
Link: Latency L0s <512ns, L1 <64us
Link: ASPM Disabled RCB 64 bytes CommClk+ ExtSynch-
Link: Speed unknown, Width x8
Capabilities: [b0] MSI-X: Enable- Mask- TabSize=32
Vector table: BAR=4 offset=00000000
PBA: BAR=4 offset=00008000
Capabilities: [d0] Vital Product Data
Capabilities: [100] Advanced Error Reporting
Capabilities: [140] Device Serial Number 88-3c-01-ff-ff-53-0f-00
Capabilities: [150] Unknown (14)
Capabilities: [160] Unknown (16)
00: 24 19 03 08 07 04 10 00 00 00 00 02 08 00 80 00
10: 01 24 00 00 00 00 00 00 04 00 00 dd 00 00 00 00
20: 04 00 01 de 00 00 00 00 00 00 00 00 24 19 05 62
30: 01 00 42 de 40 00 00 00 00 00 00 00 0b 02 00 00
40: 01 50 03 48 08 00 00 00 00 00 00 00 00 00 00 00
50: 05 70 8b 01 0c f0 e0 fe 00 00 00 00 d6 41 00 00
60: fe ff ff ff 00 00 00 00 00 00 00 00 00 00 00 00
70: 10 b0 02 00 01 86 00 10 30 20 00 00 82 3c 03 00
80: 40 00 82 10 00 00 00 00 00 00 00 00 00 00 00 00
90: 00 00 00 00 1f 00 00 00 00 00 00 00 00 00 00 00
a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
b0: 11 d0 1f 00 04 00 00 00 04 80 00 00 00 00 00 00
c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
d0: 03 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
This is how it looks in the guest:
# lspci -vv -xxx -d 1924:
00:03.0 Ethernet controller: Solarflare Communications SFC9020 [Solarstorm]
Subsystem: Solarflare Communications SFN5122F-R5
Physical Slot: 3
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-
Interrupt: pin B routed to IRQ 11
Region 0: I/O ports at c100 [size=256]
Region 2: Memory at f3000000 (32-bit, non-prefetchable) [size=16M]
Region 4: Memory at f4000000 (32-bit, non-prefetchable) [size=64K]
Expansion ROM at f4020000 [disabled] [size=128K]
Capabilities: [40] MSI: Enable- Count=1/1 Maskable- 64bit-
Address: 00000000 Data: 0000
Capabilities: [50] MSI-X: Enable- Count=32 Masked-
Vector table: BAR=4 offset=00000000
PBA: BAR=4 offset=00008000
00: 24 19 03 08 03 04 10 00 00 00 00 02 08 00 80 00
10: 01 c1 00 00 00 00 00 00 00 00 00 f3 00 00 00 00
20: 00 00 00 f4 00 00 00 00 00 00 00 00 24 19 05 62
30: 00 00 02 f4 40 00 00 00 00 00 00 00 0b 02 00 00
40: 05 50 00 00 00 00 00 00 00 00 00 00 00 00 00 00
50: 11 00 1f 00 04 00 00 00 04 80 00 00 28 41 00 00
60: fe ff ff ff 00 00 00 00 00 00 00 00 00 00 00 00
70: 10 b0 02 00 01 86 00 10 30 20 00 00 82 3c 03 00
80: 40 00 82 10 00 00 00 00 00 00 00 00 00 00 00 00
90: 00 00 00 00 1f 00 00 00 00 00 00 00 00 00 00 00
a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
b0: 11 d0 1f 00 04 00 00 00 04 80 00 00 00 00 00 00
c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
d0: 03 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
The capability list is significantly changed. The hex dump seems to
show that config space beyond about offset 0x60 is still passed through
unchanged, but I wouldn't want to rely on that remaining true.
Ben.
--
Ben Hutchings, Senior Software Engineer, Solarflare
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.
next prev parent reply other threads:[~2011-04-07 13:37 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-04-07 4:08 [PATCH net-next 2/5] be2net: use common method to check for sriov function type Ajit Khaparde
2011-04-07 8:14 ` Ben Hutchings
2011-04-07 12:34 ` Ajit.Khaparde
2011-04-07 13:37 ` Ben Hutchings [this message]
2011-04-07 19:25 ` Ajit.Khaparde
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1302183459.2878.7.camel@bwh-desktop \
--to=bhutchings@solarflare.com \
--cc=Ajit.Khaparde@Emulex.Com \
--cc=netdev@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.