linux-kernel - Re: [PATCH] pci/sriov: Add an option to probe VFs or not 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] [day] [month] [year] [list]

Date:   Wed, 22 Mar 2017 10:48:05 +1100
From:   Gavin Shan <gwshan@...ux.vnet.ibm.com>
To:     Eli Cohen <eli@...lanox.com>
Cc:     Alex Williamson <alex.williamson@...hat.com>,
        Gavin Shan <gwshan@...ux.vnet.ibm.com>,
        Bodong Wang <bodong@...lanox.com>,
        "bhelgaas@...gle.com" <bhelgaas@...gle.com>,
        "linux-pci@...r.kernel.org" <linux-pci@...r.kernel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        Saeed Mahameed <saeedm@...lanox.com>
Subject: Re: [PATCH] pci/sriov: Add an option to probe VFs or not before
 enabling SR-IOV

On Tue, Mar 21, 2017 at 02:34:46PM +0000, Eli Cohen wrote:
>> If we want to talk about the ABI, I would suggest drawing from existing ABIs.  We already have
>> drivers_autoprobe as part of the standard sysfs ABI, so if we want a binary switch, then 
>>sriov_drivers_autoprobe might be a logical choice.  If you're concerned about this mythical overhead of > binding to one driver then another, then why not draw from the driver_override interface to allow the 
>> user to specify the driver to bind to, perhaps sriov_driver_override.  Then if the user wants to bind all 
>> the devices to vfio-pci, they can do so easily.  I still fail to see that probing some fixed number of the VFs 
>> and leaving the rest unprobed has any practical value and I imagine bugs coming in because users are 
>> confused why some of their VFs behave differently than others.  Thanks,
>
>I agree with Alex - the interface should better be binary - either probe VFs or not. The rest can be done with binding/unbinding VFs as necessary. The main goal is to refrain from automatically initializing virtual functions at the hypervisor if they were initially instantiated to assign then to guests.
>

It's fairly reasonable. Thanks for confirm. I'll review v2.

Thanks,
Gavin