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:	Wed, 17 Dec 2008 10:59:34 -0800
From:	Jesse Barnes <jbarnes@...tuousgeek.org>
To:	"Fischer, Anna" <anna.fischer@...com>
Cc:	Yu Zhao <yu.zhao@...el.com>,
	"linux-pci@...r.kernel.org" <linux-pci@...r.kernel.org>,
	"Chiang, Alexander" <achiang@...com>,
	"Helgaas, Bjorn" <bjorn.helgaas@...com>,
	"grundler@...isc-linux.org" <grundler@...isc-linux.org>,
	"greg@...ah.com" <greg@...ah.com>, "mingo@...e.hu" <mingo@...e.hu>,
	"matthew@....cx" <matthew@....cx>,
	"randy.dunlap@...cle.com" <randy.dunlap@...cle.com>,
	"rdreier@...co.com" <rdreier@...co.com>,
	"horms@...ge.net.au" <horms@...ge.net.au>,
	"yinghai@...nel.org" <yinghai@...nel.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"kvm@...r.kernel.org" <kvm@...r.kernel.org>,
	"virtualization@...ts.linux-foundation.org" 
	<virtualization@...ts.linux-foundation.org>
Subject: Re: [PATCH 0/13 v7] PCI: Linux kernel SR-IOV support

On Wednesday, December 17, 2008 3:42 am Fischer, Anna wrote:
> I have two minor comments on this topic.
>
> 1) Currently the PF driver is called before the kernel initializes VFs and
> their resources, and the current API does not allow the PF driver to
> detect that easily if the allocation of the VFs and their resources
> has succeeded or not. It would be quite useful if the PF driver gets
> notified when the VFs have been created successfully as it might have
> to do further device-specific work *after* IOV has been enabled.

You're thinking of after the VFs are created the VF drivers (which may or may 
not be part of the PF driver) may not be able to communicate back to the PF 
driver that something else needs to be done (I remember seeing this in the 
earlier thread, should have included it in my post, sorry)?  I'm not sure if 
it makes sense to add an interface like that to the core until we have feel 
for what the PF/VF drivers are going to want... Or do you have something 
specific in mind right now?  If/until we have something in the core, it seems 
like this could be done on a per PF/VF driver basis for now.

> 2) Configuration of SR-IOV: the current API allows to enable/disable
> VFs from userspace via SYSFS. At the moment I am not quite clear what
> exactly is supposed to control these capabilities. This could be
> Linux tools or, on a virtualized system, hypervisor control tools.
> One thing I am missing though is an in-kernel API for this which I
> think might be useful. After all the PF driver controls the device,
> and, for example, when a device error occurs (e.g. a hardware failure
> which only the PF driver will be able to detect, not Linux), then the
> PF driver might have to de-allocate all resources, shut down VFs and
> reset the device, or something like that. In that case the PF driver
> needs to have a way to notify the Linux SR-IOV code about this and
> initiate cleaning up of VFs and their resources. At the moment, this
> would have to go through userspace, I believe, and I think that is not
> an optimal solution. Yu, do you have an opinion on how this would be
> realized?

That's a good point, Yu?

-- 
Jesse Barnes, Intel Open Source Technology Center

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