On 10/02/2017 08:35 AM, David Woodhouse wrote:
On Thu, 2017-09-28 at 12:56 -0400, Don Dutile wrote:
Well, my point is more like: why put it in uio?
why not make it available via pcie, setup while/if no driver attached?
i.e., other non-uio users can use the mechanism.... like libvirt? ...
if a PF driver isn't required.
This would allow you to enable SR-IOV on a PF before its driver is
loaded, right? Even when that driver *is* going to need to perform
resource management for those VFs?
Would existing drivers cope with SR-IOV being enabled, and VFs being
assigned to guests, before they're loaded? If so then sure, let's do it
generically. But I'm not sure that's the case.
No better than a uio driver/mgmt api that may have to configure a PF
before a VF is enabled.
Q: So what is better: provide a common hook in sysfs for all to use,
potentially causing a kernel fault (during vf probe/config), or
a user-level program/mgmt-app that does the equivalent?
As it is, the UIO driver is all about "userspace knows best". So if
there's resource management to be done, then userspace needs to do that
before enabling SR-IOV. And that's consistent with the current driver-
based enabling model for SR-IOV.
I'm not seeing the UIO driver consistency here. IMO, it's a similar
problem, moved to a different place. i.e., slightly different attack vector,
but same endpoint.
