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  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, 13 Apr 2017 09:16:34 -0500
From:   Bodong Wang <>
To:     Gavin Shan <>,
        Alex Williamson <>
CC:     <>, <>,
        <>, <>,
        Eli Cohen <>
Subject: Re: [v3] PCI: Add an option to control probing of VFs before enabling

On 4/13/2017 12:24 AM, Gavin Shan wrote:
> On Wed, Apr 12, 2017 at 08:56:14PM -0600, Alex Williamson wrote:
>> On Thu, 13 Apr 2017 01:51:40 +0300
>> wrote:
>>> From: Bodong Wang <>
>>> 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_drivers_autoprobe" 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_drivers_autoprobe
>>> Note that, the choice must be made before enabling VFs. The change
>>> will not take effect if VFs are already enabled. Simply, one can set
>>> sriov_numvfs to 0, choose whether to probe or not, and then resume
>>> sriov_numvfs.
>>> Signed-off-by: Bodong Wang <>
>>> Signed-off-by: Eli Cohen <>
>>> Reviewed-by: Gavin Shan <>
>>> Reviewed-by: Alex Williamson <>
>> Whoa, I reviewed the last version, that's different than providing a
>> Reviewed-by, and I've certainly never seen this version until now, so I
>> can't possibly have endorsed it in any way.  It's also changed since
>> Gavin saw it and I think Bjorn is in the same boat.  Probably a good
>> idea to cc the people you're claiming reviewed this too (cc +Gavin).
> Thanks, Alex. I usually keep an eye on the patches that I ever
> reviewed and follow them until they are merged or rejected. More
> comments would be given if I have. Otherwise, everthing is fine.
> Yes, it's always nice to copy those who reviewed the patch.
> For this one, my reviewed-by is still valid.
> Thanks,
> Gavin
Thanks Alex/Gavin for the suggestion. Will follow this pattern in the 

Powered by blists - more mailing lists