All of lore.kernel.org
 help / color / mirror / Atom feed
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.


  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.