netdev - Re: [PATCH RFC] pci: Control whether VFs are probed on pci_enable

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:	Tue, 09 Dec 2014 12:24:14 -0500
From:	Don Dutile <ddutile@...hat.com>
To:	Yuval Mintz <Yuval.Mintz@...gic.com>,
	Eli Cohen <eli@....mellanox.co.il>
CC:	"bhelgaas@...gle.com" <bhelgaas@...gle.com>,
	David Miller <davem@...emloft.net>,
	linux-pci <linux-pci@...r.kernel.org>,
	netdev <netdev@...r.kernel.org>,
	"ogerlitz@...lanox.com" <ogerlitz@...lanox.com>,
	"yevgenyp@...lanox.com" <yevgenyp@...lanox.com>
Subject: Re: [PATCH RFC] pci: Control whether VFs are probed on pci_enable_sriov

On 12/09/2014 02:07 AM, Yuval Mintz wrote:
>>>> Currently the kerenl will call probe for any device for which there
>>>> is a supporting driver and I did not want to change that.
>>>
>>> But what's next? How will this feature be activated?
>>>
>>> Adding a parameter to pci_enable_sriov() might give developers the
>>> false impression they can change behavior by passing `0' to this
>>> function; But that shouldn't be the method to control this - we should
>>> have uniform control of the feature across different drivers, e.g., by an
>> additional sysfs node.
>>
>> I was planning on using this on mlx5 SRIOV support which is not available
>> upstream yet. So this could be a driver developer's decision how to use this.
>
> I think it shouldn't - from user perspective, you can't have such fundamental
> difference between different drivers - that enabling sriov on one device would
> create VFs in the hypervisors and another one won't.
>
>> I think adding another sysfs entry to control this behavior is unnecessary since the
>> administrator has the freedom to later do any bidnings he wishes to do.
>>
>> Keeping things as they are today is not so "nice". I mean, I could fail probe for
>> VFs to avoid them from being initialized at the hypervisor but there are other
>> questions: which error should I return and how can I be sure how the bus driver
>> will refer to such failures.
>
> Again - you could say that this is solely in your drivers decision-making-area,
> but failing the VF probe would lead to the same difference between drivers I've
> stated before.
>
>> So, maybe the solution I suggested is not the best one but do we agree that this
>> needs to be addressed this way or another?
>
> All-in-all, I agree. But I think the solution should be user-controlled and not driver-based.
>
So, I still haven't heard the reasons why the VF driver does not want
to be configured in the host/hypervisor.  Please expound.  As this solution only
solves it on the first sriov_enable(), and not subsequent deassign of VFs from VMs.

If the desire is to never have the VF driver running on the host, just
blacklist the VF driver.  If you use the same driver for both, then
make a simple VF shell driver (includes the same driver), and have it
pci-id match the VF only, and blacklist it in modprobe.conf .
That only wastes some binary space for the dupe'd driver, but it resolves
this situation in a user-driven manner.

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