Messages in this thread | | | Subject | Re: [PATCH] uio/uio_pci_generic: Add SR-IOV support | From | Don Dutile <> | Date | Mon, 2 Oct 2017 18:02:55 -0400 |
| |
On 10/02/2017 03:10 PM, David Woodhouse wrote: > On Mon, 2017-10-02 at 14:52 -0400, Don Dutile wrote: >> On 10/02/2017 08:35 AM, David Woodhouse wrote: >>> 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. > > Conceptually, the current model is that you don't have SR-IOV until you > have a driver loaded for the physical function which can do any > necessary resource management. > > That's *why* the generic "sriov_numvfs" interface in sysfs isn't > present until such a driver is loaded. > > In the UIO case, *userspace* is responsible for the PF. So it's not an > "attack vector"; we let userspace do what it likes with the PF and that > includes enabling SR-IOV too. > > Do we actually *disable* SR-IOV when a (UIO or in-kernel) driver for > the PF is unloaded? If not, that's the only "attack vector" I see — to > load a driver which permits SR-IOV to be enabled, and do so, and then > unload it and load a different driver which doesn't cope. > > And each driver in that scenario can be either an in-kernel driver or > UIO+userspace; it doesn't matter either way. The patch I sent is just > following the *existing* model. > > But sure, my question was intended to ask whether we want to *stick* > with that model. Given the answers I got, my own conclusion was that we > probably do... > ok. got the whole picture now. +1 to your reply.
| |