netdev - RE: [PATCH net-next 2/5] be2net: use common method to check for sriov function type

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <49395329523DD64492581B505F80C86D5A5BCD3948@EXMAIL.ad.emulex.com>
Date:	Thu, 7 Apr 2011 12:25:31 -0700
From:	<Ajit.Khaparde@...lex.Com>
To:	<bhutchings@...arflare.com>
CC:	<netdev@...r.kernel.org>
Subject: RE: [PATCH net-next 2/5] be2net: use common method to check for
 sriov function type

________________________________________
From: Ben Hutchings [bhutchings@...arflare.com]
Sent: Thursday, April 07, 2011 8:37 AM
To: Khaparde, Ajit
Cc: netdev@...r.kernel.org
Subject: RE: [PATCH net-next 2/5] be2net: use common method to check for sriov function type

On Thu, 2011-04-07 at 05:34 -0700, Ajit.Khaparde@...lex.Com wrote:
> ________________________________________
> > From: Ben Hutchings [bhutchings@...arflare.com]
> > Sent: Thursday, April 07, 2011 3:14 AM
> > To: Khaparde, Ajit
> > Cc: netdev@...r.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.

> 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.

Oh ok. I see some difference in the lspci output on my setup too.
And when I load my driver, the PF is identified properly when I assign it as a passthrough device in a VM.
It does not have the same capability list as in the KVM Hypervisor though.

-Ajit

> 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.--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html