[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

[libvirt] [PATCH] Force FLR on for buggy SR-IOV devices.



Some buggy PCI devices actually support FLR, but
forget to advertise that fact in their PCI config space.
However, Virtual Functions on SR-IOV devices are
*required* to support FLR by the spec, so force has_flr
on if this is a virtual function.

Signed-off-by: Chris Lalancette <clalance redhat com>
---
 src/util/pci.c |   22 ++++++++++++++++++++++
 1 files changed, 22 insertions(+), 0 deletions(-)

diff --git a/src/util/pci.c b/src/util/pci.c
index c45b179..4bfad2c 100644
--- a/src/util/pci.c
+++ b/src/util/pci.c
@@ -385,6 +385,7 @@ pciDetectFunctionLevelReset(pciDevice *dev)
 {
     uint32_t caps;
     uint8_t pos;
+    char *path;
 
     /* The PCIe Function Level Reset capability allows
      * individual device functions to be reset without
@@ -413,6 +414,27 @@ pciDetectFunctionLevelReset(pciDevice *dev)
         }
     }
 
+    /* there are some buggy devices that do support FLR, but forget to
+     * advertise that fact in their capabilities.  However, FLR is *required*
+     * to be present for virtual functions (VFs), so if we see that this
+     * device is a VF, we just assume FLR works
+     */
+
+    if (virAsprintf(&path, PCI_SYSFS "devices/%s/physfn", dev->name) < 0) {
+        VIR_ERROR("Failed to allocate memory when checking FLR for device %s",
+                  dev->id);
+        return 0;
+    }
+
+    if (virFileExists(path)) {
+        VIR_FREE(path);
+        VIR_DEBUG("%s %s: buggy device didn't advertise FLR, but is a VF; forcing flr on",
+                  dev->id, dev->name);
+        return 1;
+    }
+
+    VIR_FREE(path);
+
     VIR_DEBUG("%s %s: no FLR capability found", dev->id, dev->name);
 
     return 0;
-- 
1.7.1.1


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]