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] [thread-next>] [day] [month] [year] [list]
Date:	Thu, 3 Jun 2010 10:57:34 +0800
From:	Frank Pan <frankpzh@...il.com>
To:	"Williams, Mitch A" <mitch.a.williams@...el.com>
Cc:	Greg KH <greg@...ah.com>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Jesse Barnes <jbarnes@...tuousgeek.org>,
	Kenji Kaneshige <kaneshige.kenji@...fujitsu.com>,
	Yu Zhao <yu.zhao@...el.com>,
	Chris Wright <chrisw@...s-sol.org>,
	"Rafael J. Wysocki" <rjw@...k.pl>,
	"David S. Miller" <davem@...emloft.net>,
	Matt Carlson <mcarlson@...adcom.com>,
	"linux-pci@...r.kernel.org" <linux-pci@...r.kernel.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: Add a helper function in PCI IOV to get VF device

hi Mitch,

> Frank, I'm not sure what you're trying to accomplish here. All of the information you need is already in sysfs. Given the PF device, you can look at /sys/class/net/ethX/device/virtfnX to get the bus/device/function of each of the VF devices.

Yes, that's the most funny part. Sysfs can only be traversed in
usespace. So the thing userspace knows isn't known by driver(pf driver
have no idea about vf's bdf), while the thing driver knows isn't known
by userspace(one cannot infer pf's bdf from vf's bdf).
Please think kernel/userspace as 2 system, they can hardly communicate
these informations. IMHO give a syscall/ioctl telling these is funny
and strange.

> If the VF driver is loaded in your kernel, then given the bus/device/function of the vf device, you can look at /sys/class/net/ethX/device/virtfnX/net to see which interface corresponds to that VF.

VF driver will never be loaded on physical machine, it can only be
loaded in a virtual machine. On a physical machine, VF won't have any
interface.

> Furthermore, if the VF driver is loaded, you can find the PF device by looking at /sys/class/net/ethX/device/physfn, and you can find out which interface it is by looking at /sys/class/net/ethX/device/physfn/net

So, when VF has no interface, this path is also unavailable. That's
why I say given vf's bdf, one cannot infer pf's.

> The current PF drivers (both ixgbe and igb) do not directly manipulate sysfs at all, so there is no /sys/class/net/ethX/vfX. If you see this setup, you are using a very, very old version of the igb driver, which is not supported at all. Please upgrade to a recent kernel/driver combination.

You are right, vfX is not available now. Anyway, I'm hacking igb
driver to provide informations about vf into userspace. When driver
don't know vf's bdf and userspace don't know pf's bdf, this thing
cannot be done. That's the motivation of this patch.

Don't forget another one: PF cannot access VF's PCI space. This is
also a <maybe common> use case. I need this to dump/change the VF's
PCI space.

Thanks for reply.

-- 
Frank Pan

Computer Science and Technology
Tsinghua University
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ