Re: [libvirt] [PATCH v2] PCI: Introduce new device binding path using pci_dev.driver_override

2014-05-16 Thread Konrad Rzeszutek Wilk
On Fri, May 16, 2014 at 10:48:00AM -0400, Konrad Rzeszutek Wilk wrote:
> On Fri, May 9, 2014 at 12:50 PM, Alex Williamson  > wrote:
> 
> > The driver_override field allows us to specify the driver for a device
> > ...
> >
> ...
> 
> > Signed-off-by: Alex Williamson 
> > Cc: Greg Kroah-Hartman 
> >
> 
> Reviewed-by: Konrad Rzeszutek Wilk 

And somehow my emailer (Google) decided to add yucky HTML crud
to the end.

So here is an nice plain email so that it can go the the right
mailing lists - and sorry for the extra emails to those on the
'To' and 'CC'!
> ___
> iommu mailing list
> io...@lists.linux-foundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/iommu

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list


Re: [libvirt] [PATCH v2] PCI: Introduce new device binding path using pci_dev.driver_override

2014-05-16 Thread Konrad Rzeszutek Wilk
On Fri, May 9, 2014 at 12:50 PM, Alex Williamson  wrote:

> The driver_override field allows us to specify the driver for a device
> ...
>
...

> Signed-off-by: Alex Williamson 
> Cc: Greg Kroah-Hartman 
>

Reviewed-by: Konrad Rzeszutek Wilk 
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

Re: [libvirt] [PATCH v2] PCI: Introduce new device binding path using pci_dev.driver_override

2014-05-19 Thread Alexander Graf


On 09.05.14 18:50, Alex Williamson wrote:

The driver_override field allows us to specify the driver for a device
rather than relying on the driver to provide a positive match of the
device.  This shortcuts the existing process of looking up the vendor
and device ID, adding them to the driver new_id, binding the device,
then removing the ID, but it also provides a couple advantages.

First, the above existing process allows the driver to bind to any
device matching the new_id for the window where it's enabled.  This is
often not desired, such as the case of trying to bind a single device
to a meta driver like pci-stub or vfio-pci.  Using driver_override we
can do this deterministically using:

echo pci-stub > /sys/bus/pci/devices/:03:00.0/driver_override
echo :03:00.0 > /sys/bus/pci/devices/:03:00.0/driver/unbind
echo :03:00.0 > /sys/bus/pci/drivers_probe

Previously we could not invoke drivers_probe after adding a device
to new_id for a driver as we get non-deterministic behavior whether
the driver we intend or the standard driver will claim the device.
Now it becomes a deterministic process, only the driver matching
driver_override will probe the device.

To return the device to the standard driver, we simply clear the
driver_override and reprobe the device:

echo > /sys/bus/pci/devices/:03:00.0/driver_override
echo :03:00.0 > /sys/bus/pci/devices/:03:00.0/driver/unbind
echo :03:00.0 > /sys/bus/pci/drivers_probe

Another advantage to this approach is that we can specify a driver
override to force a specific binding or prevent any binding.  For
instance when an IOMMU group is exposed to userspace through VFIO
we require that all devices within that group are owned by VFIO.
However, devices can be hot-added into an IOMMU group, in which case
we want to prevent the device from binding to any driver (override
driver = "none") or perhaps have it automatically bind to vfio-pci.
With driver_override it's a simple matter for this field to be set
internally when the device is first discovered to prevent driver
matches.

Signed-off-by: Alex Williamson 
Cc: Greg Kroah-Hartman 
---

v2: Use strchr() as suggested by Guenter Roeck and adopted by the
 platform driver version of this same interface.

  Documentation/ABI/testing/sysfs-bus-pci |   21 
  drivers/pci/pci-driver.c|   25 +--
  drivers/pci/pci-sysfs.c |   40 +++
  include/linux/pci.h |1 +
  4 files changed, 84 insertions(+), 3 deletions(-)

diff --git a/Documentation/ABI/testing/sysfs-bus-pci 
b/Documentation/ABI/testing/sysfs-bus-pci
index a3c5a66..898ddc4 100644
--- a/Documentation/ABI/testing/sysfs-bus-pci
+++ b/Documentation/ABI/testing/sysfs-bus-pci
@@ -250,3 +250,24 @@ Description:
valid.  For example, writing a 2 to this file when sriov_numvfs
is not 0 and not 2 already will return an error. Writing a 10
when the value of sriov_totalvfs is 8 will return an error.
+
+What:  /sys/bus/pci/devices/.../driver_override
+Date:  April 2014
+Contact:   Alex Williamson 
+Description:
+   This file allows the driver for a device to be specified which
+   will override standard static and dynamic ID matching.  When
+   specified, only a driver with a name matching the value written
+   to driver_override will have an opportunity to bind to the
+   device.  The override is specified by writing a string to the
+   driver_override file (echo pci-stub > driver_override) and
+   may be cleared with an empty string (echo > driver_override).
+   This returns the device to standard matching rules binding.
+   Writing to driver_override does not automatically unbind the
+   device from its current driver or make any attempt to
+   automatically load the specified driver.  If no driver with a
+   matching name is currently loaded in the kernel, the device
+   will not bind to any driver.  This also allows devices to
+   opt-out of driver binding using a driver_override name such as
+   "none".  Only a single driver may be specified in the override,
+   there is no support for parsing delimiters.
diff --git a/drivers/pci/pci-driver.c b/drivers/pci/pci-driver.c
index d911e0c..4393c12 100644
--- a/drivers/pci/pci-driver.c
+++ b/drivers/pci/pci-driver.c
@@ -216,6 +216,13 @@ const struct pci_device_id *pci_match_id(const struct 
pci_device_id *ids,
return NULL;
  }
  
+static const struct pci_device_id pci_device_id_any = {

+   .vendor = PCI_ANY_ID,
+   .device = PCI_ANY_ID,
+   .subvendor = PCI_ANY_ID,
+   .subdevice = PCI_ANY_ID,
+};
+
  /**
   * pci_match_device - Tell if a PCI device structure has a matching PCI 
device id structure
   * @drv: t