linux-kernel - Re: [v2] PCI: Add an option to control probing of VFs before enabling SR-IOV

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, 12 Apr 2017 09:37:22 -0500
From:   Bodong Wang <bodong@...lanox.com>
To:     Bjorn Helgaas <helgaas@...nel.org>
CC:     <bhelgaas@...gle.com>, <linux-pci@...r.kernel.org>,
        <linux-kernel@...r.kernel.org>, <saeedm@...lanox.com>,
        Eli Cohen <eli@...lanox.com>
Subject: Re: [v2] PCI: Add an option to control probing of VFs before enabling
 SR-IOV

On 4/11/2017 4:12 PM, Bjorn Helgaas wrote:
> Hi Bodong,
>
> On Wed, Mar 22, 2017 at 05:53:58PM +0200, bodong@...lanox.com wrote:
>> From: Bodong Wang <bodong@...lanox.com>
>>
>> Sometimes it is not desirable to probe the virtual functions after
>> SRIOV is enabled. This can save host side resource usage by VF
>> instances which would be eventually probed to VMs.
>>
>> Add a new PCI sysfs interface "sriov_probe_vfs" to control that
>> from the PF, all current callers still retain the same functionality.
>> To modify it, echo 0/n/N (disable probe) or 1/y/Y (enable probe) to
>>
>> /sys/bus/pci/devices/<DOMAIN:BUS:DEVICE.FUNCTION>/sriov_probe_vfs
> Is this basically the same functionality as /sys/bus/pci/drivers_autoprobe,
> but limited to a specific PF?  I.e., could we accomplish the same thing
> with the following?
>
>    # echo 0 > /sys/bus/pci/devices/DDDD:BB:dd.f/sriov_numvfs
>    # echo 0 > /sys/bus/pci/drivers_autoprobe
>    # echo 2 > /sys/bus/pci/devices/DDDD:BB:dd.f/sriov_numvfs
>    # echo 1 > /sys/bus/pci/drivers_autoprobe
>
> If not, can you contrast the above with drivers_autoprobe?  If we need
> both, should they be named more similarly?
Hi Bjorn,

I agree with Alex about not using driver_autoprobe to achieve this. It 
will affect all pci related device once it's disabled(probably in a bad 
way). On the other hand, current pci driver doesn't work for this use 
case at all. VFs drivers(if any) will be probed once sriov is enabled no 
matter what. The code path is pci_enable_sriov-> 
pci_bus_add_device->device_attach, and drivers will be probed at the 
end. Drivers_autoprobe only prevents probing pci_device_add is called. 
This patch bounded the change to the device itself and requires no 
device driver update.

For the name convention, it's aligned with other sriov related sysfs 
entries. Let me know if you have better options.

Thanks,

Bodong