linux-kernel - Re: [PATCH 0/16 v6] PCI: Linux kernel SR-IOV support

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]

Message-ID: <20081106175308.GA17027@kroah.com>
Date:	Thu, 6 Nov 2008 09:53:08 -0800
From:	Greg KH <greg@...ah.com>
To:	Matthew Wilcox <matthew@....cx>
Cc:	H L <swdevyid@...oo.com>, Yu Zhao <yu.zhao@...el.com>,
	randy.dunlap@...cle.com, grundler@...isc-linux.org, achiang@...com,
	linux-pci@...r.kernel.org, rdreier@...co.com,
	linux-kernel@...r.kernel.org, jbarnes@...tuousgeek.org,
	virtualization@...ts.linux-foundation.org, kvm@...r.kernel.org,
	mingo@...e.hu, Chris Wright <chrisw@...s-sol.org>
Subject: Re: [PATCH 0/16 v6] PCI: Linux kernel SR-IOV support

On Thu, Nov 06, 2008 at 10:47:41AM -0700, Matthew Wilcox wrote:
> On Thu, Nov 06, 2008 at 08:49:19AM -0800, Greg KH wrote:
> > On Thu, Nov 06, 2008 at 08:41:53AM -0800, H L wrote:
> > > I have not modified any existing drivers, but instead I threw together
> > > a bare-bones module enabling me to make a call to pci_iov_register()
> > > and then poke at an SR-IOV adapter's /sys entries for which no driver
> > > was loaded.
> > > 
> > > It appears from my perusal thus far that drivers using these new
> > > SR-IOV patches will require modification; i.e. the driver associated
> > > with the Physical Function (PF) will be required to make the
> > > pci_iov_register() call along with the requisite notify() function.
> > > Essentially this suggests to me a model for the PF driver to perform
> > > any "global actions" or setup on behalf of VFs before enabling them
> > > after which VF drivers could be associated.
> > 
> > Where would the VF drivers have to be associated?  On the "pci_dev"
> > level or on a higher one?
> > 
> > Will all drivers that want to bind to a "VF" device need to be
> > rewritten?
> 
> The current model being implemented by my colleagues has separate
> drivers for the PF (aka native) and VF devices.  I don't personally
> believe this is the correct path, but I'm reserving judgement until I
> see some code.

Hm, I would like to see that code before we can properly evaluate this
interface.  Especially as they are all tightly tied together.

> I don't think we really know what the One True Usage model is for VF
> devices.  Chris Wright has some ideas, I have some ideas and Yu Zhao has
> some ideas.  I bet there's other people who have other ideas too.

I'd love to hear those ideas.

Rumor has it, there is some Xen code floating around to support this
already, is that true?

thanks,

greg k-h
--
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/