On 12/09/2014 02:07 AM, Yuval Mintz wrote:
Currently the kerenl will call probe for any device for which there
is a supporting driver and I did not want to change that.
But what's next? How will this feature be activated?
Adding a parameter to pci_enable_sriov() might give developers the
false impression they can change behavior by passing `0' to this
function; But that shouldn't be the method to control this - we should
have uniform control of the feature across different drivers, e.g., by an
additional sysfs node.
I was planning on using this on mlx5 SRIOV support which is not available
upstream yet. So this could be a driver developer's decision how to use this.
I think it shouldn't - from user perspective, you can't have such fundamental
difference between different drivers - that enabling sriov on one device would
create VFs in the hypervisors and another one won't.
I think adding another sysfs entry to control this behavior is unnecessary since the
administrator has the freedom to later do any bidnings he wishes to do.
Keeping things as they are today is not so "nice". I mean, I could fail probe for
VFs to avoid them from being initialized at the hypervisor but there are other
questions: which error should I return and how can I be sure how the bus driver
will refer to such failures.
Again - you could say that this is solely in your drivers decision-making-area,
but failing the VF probe would lead to the same difference between drivers I've
stated before.
So, maybe the solution I suggested is not the best one but do we agree that this
needs to be addressed this way or another?
All-in-all, I agree. But I think the solution should be user-controlled and not driver-based.
So, I still haven't heard the reasons why the VF driver does not want
to be configured in the host/hypervisor. Please expound. As this solution only
solves it on the first sriov_enable(), and not subsequent deassign of VFs from VMs.
If the desire is to never have the VF driver running on the host, just
blacklist the VF driver. If you use the same driver for both, then
make a simple VF shell driver (includes the same driver), and have it
pci-id match the VF only, and blacklist it in modprobe.conf .
That only wastes some binary space for the dupe'd driver, but it resolves
this situation in a user-driven manner.
--
To unsubscribe from this list: send the line "unsubscribe linux-pci" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
