[PATCH 1/2] pci: Error disabling SR-IOV if in VFs assigned

[Alex Williamson]

On Mon, 23 May 2016 03:55:32 -0700
Christoph Hellwig <hch at infradead.org> wrote:

> On Tue, May 17, 2016 at 04:08:32PM -0600, Alex Williamson wrote:
> > On Tue, 17 May 2016 15:39:58 -0600
> > Keith Busch <keith.busch at intel.com> wrote:
> >   
> > > Every sriov capable driver has to check if any guest is using a virtual
> > > function prior to disabling, so let's make it common code.  
> > 
> > This is not true, the PCI_DEV_FLAGS_ASSIGNED flag is inherently racy,
> > so checking it is really only a courtesy for broken drivers that
> > still make use of it.  I don't object to adding it here, though I
> > wish the entire interface was deprecated, but it's only a minimal amount
> > of insurance as a VF might get assigned immediately following your added
> > test or might not participate in the assigned device flagging at all.  
> 
> Si should we just kill it? As far as I can tell it's only used in these
> kinds of boilerplate checks.

Long term, yes, but perhaps KVM legacy PCI device assignment needs to
be not only deprecated, but removed first.

> > I
> > believe the better way to handle this is with proper host drivers for
> > assigned devices that manage the driver .remove callback properly while
> > devices are in use.  The only reason to handle assigned devices
> > specially in this case is when they don't have proper host drivers
> > managing them, which is a problem that we've fixed.  Thanks,  
> 
> We always use pci-stub now, don't we?

pci-stub's only purpose is to prevent other drivers from binding to a
device, such as while it's in used by legacy KVM device assignment.
pci-stub has no visibility whether a device is in use or not, and will
happily unbind the device at any point in time.  Thus legacy KVM device
assignment with pci-stub makes use of this horrible flag in a vain
attempt to prevent devices from disappearing, littering every possible
remove path with these sorts of checks when really the driver holding
the assigned device should block or maybe allow an error return from
the .remove callback.  Xen pci-back also sets this flag, but I would
hope there's a sensible solution available there and they just adopted
use of this flag without really questioning that it works or makes
sense. Thanks,

Alex