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  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 15:24:50 +1000
From:   Gavin Shan <gwshan@...ux.vnet.ibm.com>
To:     Alex Williamson <alex.williamson@...hat.com>
Cc:     bodong@...lanox.com, helgaas@...nel.org, linux-pci@...r.kernel.org,
        linux-kernel@...r.kernel.org, saeedm@...lanox.com,
        Eli Cohen <eli@...lanox.com>, gwshan@...ux.vnet.ibm.com
Subject: Re: [v3] PCI: Add an option to control probing of VFs before
 enabling SR-IOV

On Wed, Apr 12, 2017 at 08:56:14PM -0600, Alex Williamson wrote:
>On Thu, 13 Apr 2017 01:51:40 +0300
>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_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 <bodong@...lanox.com>
>> Signed-off-by: Eli Cohen <eli@...lanox.com>
>> Reviewed-by: Gavin Shan <gwshan@...ux.vnet.ibm.com>
>> Reviewed-by: Alex Williamson <alex.williamson@...hat.com>
>
>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

Powered by blists - more mailing lists