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] [thread-next>] [day] [month] [year] [list]

Date:   Tue, 21 Mar 2017 14:34:46 +0000
From:   Eli Cohen <eli@...lanox.com>
To:     Alex Williamson <alex.williamson@...hat.com>,
        Gavin Shan <gwshan@...ux.vnet.ibm.com>
CC:     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

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