1. 01 Sep, 2017 1 commit
  2. 24 Aug, 2017 1 commit
  3. 10 Aug, 2017 2 commits
  4. 19 Jun, 2017 1 commit
  5. 14 Jun, 2017 1 commit
  6. 20 Apr, 2017 4 commits
  7. 18 Apr, 2017 2 commits
  8. 12 Apr, 2017 1 commit
  9. 03 Feb, 2017 1 commit
    • Emil Tantilov's avatar
      PCI: Lock each enable/disable num_vfs operation in sysfs · 5b0948df
      Emil Tantilov authored
      Enabling/disabling SRIOV via sysfs by echo-ing multiple values
      simultaneously:
      
        # echo 63 > /sys/class/net/ethX/device/sriov_numvfs&
        # echo 63 > /sys/class/net/ethX/device/sriov_numvfs
      
        # sleep 5
      
        # echo 0 > /sys/class/net/ethX/device/sriov_numvfs&
        # echo 0 > /sys/class/net/ethX/device/sriov_numvfs
      
      results in the following bug:
      
        kernel BUG at drivers/pci/iov.c:495!
        invalid opcode: 0000 [#1] SMP
        CPU: 1 PID: 8050 Comm: bash Tainted: G   W   4.9.0-rc7-net-next #2092
        RIP: 0010:[<ffffffff813b1647>]
      	    [<ffffffff813b1647>] pci_iov_release+0x57/0x60
      
        Call Trace:
         [<ffffffff81391726>] pci_release_dev+0x26/0x70
         [<ffffffff8155be6e>] device_release+0x3e/0xb0
         [<ffffffff81365ee7>] kobject_cleanup+0x67/0x180
         [<ffffffff81365d9d>] kobject_put+0x2d/0x60
         [<ffffffff8155bc27>] put_device+0x17/0x20
         [<ffffffff8139c08a>] pci_dev_put+0x1a/0x20
         [<ffffffff8139cb6b>] pci_get_dev_by_id+0x5b/0x90
         [<ffffffff8139cca5>] pci_get_subsys+0x35/0x40
         [<ffffffff8139ccc8>] pci_get_device+0x18/0x20
         [<ffffffff8139ccfb>] pci_get_domain_bus_and_slot+0x2b/0x60
         [<ffffffff813b09e7>] pci_iov_remove_virtfn+0x57/0x180
         [<ffffffff813b0b95>] pci_disable_sriov+0x65/0x140
         [<ffffffffa00a1af7>] ixgbe_disable_sriov+0xc7/0x1d0 [ixgbe]
         [<ffffffffa00a1e9d>] ixgbe_pci_sriov_configure+0x3d/0x170 [ixgbe]
         [<ffffffff8139d28c>] sriov_numvfs_store+0xdc/0x130
        ...
        RIP  [<ffffffff813b1647>] pci_iov_release+0x57/0x60
      
      Use the existing mutex lock to protect each enable/disable operation.
      Signed-off-by: default avatarEmil Tantilov <emil.s.tantilov@intel.com>
      Signed-off-by: default avatarBjorn Helgaas <bhelgaas@google.com>
      Reviewed-by: default avatarGavin Shan <gwshan@linux.vnet.ibm.com>
      CC: Alexander Duyck <alexander.h.duyck@intel.com>
      5b0948df
  10. 21 Nov, 2016 1 commit
  11. 13 Jun, 2016 1 commit
    • Mika Westerberg's avatar
      PCI: Put PCIe ports into D3 during suspend · 9d26d3a8
      Mika Westerberg authored
      Currently the Linux PCI core does not touch power state of PCI bridges and
      PCIe ports when system suspend is entered.  Leaving them in D0 consumes
      power unnecessarily and may prevent the CPU from entering deeper C-states.
      
      With recent PCIe hardware we can power down the ports to save power given
      that we take into account few restrictions:
      
        - The PCIe port hardware is recent enough, starting from 2015.
      
        - Devices connected to PCIe ports are effectively in D3cold once the port
          is transitioned to D3 (the config space is not accessible anymore and
          the link may be powered down).
      
        - Devices behind the PCIe port need to be allowed to transition to D3cold
          and back.  There is a way both drivers and userspace can forbid this.
      
        - If the device behind the PCIe port is capable of waking the system it
          needs to be able to do so from D3cold.
      
      This patch adds a new flag to struct pci_device called 'bridge_d3'.  This
      flag is set and cleared by the PCI core whenever there is a change in power
      management state of any of the devices behind the PCIe port.  When system
      later on is suspended we only need to check this flag and if it is true
      transition the port to D3 otherwise we leave it in D0.
      
      Also provide override mechanism via command line parameter
      "pcie_port_pm=[off|force]" that can be used to disable or enable the
      feature regardless of the BIOS manufacturing date.
      Tested-by: default avatarLukas Wunner <lukas@wunner.de>
      Signed-off-by: default avatarMika Westerberg <mika.westerberg@linux.intel.com>
      Signed-off-by: default avatarBjorn Helgaas <bhelgaas@google.com>
      Acked-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
      9d26d3a8
  12. 25 Apr, 2016 1 commit
    • Bjorn Helgaas's avatar
      PCI: Supply CPU physical address (not bus address) to iomem_is_exclusive() · ca620723
      Bjorn Helgaas authored
      iomem_is_exclusive() requires a CPU physical address, but on some arches we
      supplied a PCI bus address instead.
      
      On most arches, pci_resource_to_user(res) returns "res->start", which is a
      CPU physical address.  But on microblaze, mips, powerpc, and sparc, it
      returns the PCI bus address corresponding to "res->start".
      
      The result is that pci_mmap_resource() may fail when it shouldn't (if the
      bus address happens to match an existing resource), or it may succeed when
      it should fail (if the resource is exclusive but the bus address doesn't
      match it).
      
      Call iomem_is_exclusive() with "res->start", which is always a CPU physical
      address, not the result of pci_resource_to_user().
      
      Fixes: e8de1481 ("resource: allow MMIO exclusivity for device drivers")
      Suggested-by: default avatarYinghai Lu <yinghai@kernel.org>
      Signed-off-by: default avatarBjorn Helgaas <bhelgaas@google.com>
      CC: Arjan van de Ven <arjan@linux.intel.com>
      ca620723
  13. 14 Apr, 2016 1 commit
    • Linus Torvalds's avatar
      pci-sysfs: use proper file capability helper function · ab0fa82b
      Linus Torvalds authored
      The PCI config access checked the file capabilities correctly, but used
      the itnernal security capability check rather than the helper function
      that is actually meant for that.
      
      The security_capable() has unusual return values and is not meant to be
      used elsewhere (the only other use is in the capability checking
      functions that we actually intend people to use, and this odd PCI usage
      really stood out when looking around the capability code.
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      ab0fa82b
  14. 12 Mar, 2016 4 commits
  15. 29 Feb, 2016 2 commits
  16. 08 Jan, 2016 1 commit
  17. 11 Dec, 2015 1 commit
  18. 24 Nov, 2015 1 commit
    • Mathias Krause's avatar
      PCI: Prevent out of bounds access in numa_node override · 3dcc8d39
      Mathias Krause authored
      Commit 12669631 ("PCI: Prevent out of bounds access in numa_node
      override") missed that the user-provided node could also be negative.
      Handle this case as well to avoid out-of-bounds accesses to the
      node_states[] array.  However, allow the special value -1, i.e.
      NUMA_NO_NODE, to be able to set the 'no specific node' configuration.
      
      Fixes: 12669631 ("PCI: Prevent out of bounds access in numa_node override")
      Fixes: 63692df1 ("PCI: Allow numa_node override via sysfs")
      Signed-off-by: default avatarMathias Krause <minipli@googlemail.com>
      Signed-off-by: default avatarBjorn Helgaas <bhelgaas@google.com>
      CC: Sasha Levin <sasha.levin@oracle.com>
      CC: Prarit Bhargava <prarit@redhat.com>
      CC: stable@vger.kernel.org	# v3.19+
      3dcc8d39
  19. 07 Oct, 2015 1 commit
  20. 24 Feb, 2015 1 commit
  21. 03 Dec, 2014 1 commit
  22. 07 Nov, 2014 1 commit
  23. 06 Nov, 2014 1 commit
    • Prarit Bhargava's avatar
      PCI: Allow numa_node override via sysfs · 63692df1
      Prarit Bhargava authored
      NUMA systems with ACPI normally describe the physical topology via _PXM
      methods.  But many BIOSes don't implement _PXM, which leaves the kernel
      with no way to discover the device topology, which reduces performance
      because we can't put memory and processes close to the device.
      
      The NUMA node of a PCI device is already exported in the sysfs "numa_node"
      file.  Make that file writable so users can workaround the lack of _PXM
      methods in the BIOS.  For example:
      
        echo 3 > /sys/devices/pci0000:ff/0000:03:1f.3/numa_node
      
      sets the node for PCI device 0000:03:1f.3.
      
      Writing the file emits a FW_BUG warning to encourage users to request
      firmware updates.  It also taints the kernel with TAINT_FIRMWARE_WORKAROUND
      because overriding the node incorrectly can cause performance issues.
      
      [bhelgaas: changelog, documentation text]
      Signed-off-by: Prarit Bhargava's avatarPrarit Bhargava <prarit@redhat.com>
      Signed-off-by: default avatarBjorn Helgaas <bhelgaas@google.com>
      CC: Myron Stowe <mstowe@redhat.com>
      CC: Alexander Ducyk <alexander.h.duyck@redhat.com>
      CC: Jiang Liu <jiang.liu@linux.intel.com>
      63692df1
  24. 30 Oct, 2014 1 commit
  25. 01 Oct, 2014 1 commit
    • Yijing Wang's avatar
      PCI/MSI: Add "msi_bus" sysfs MSI/MSI-X control for endpoints · 468ff15a
      Yijing Wang authored
      The "msi_bus" sysfs file for bridges sets a bus flag to allow or disallow
      future driver requests for MSI or MSI-X.  Previously, the sysfs file
      existed for endpoints but did nothing.
      
      Add "msi_bus" support for endpoints, so an administrator can prevent the
      use of MSI and MSI-X for individual devices.
      
      Note that as for bridges, these changes only affect future driver requests
      for MSI or MSI-X, so drivers may need to be reloaded.
      
      Add documentation for the "msi_bus" sysfs file.
      
      [bhelgaas: changelog, comments, add "subordinate", add endpoint printk,
      rework bus_flags setting, make bus_flags printk unconditional]
      Signed-off-by: default avatarYijing Wang <wangyijing@huawei.com>
      Signed-off-by: default avatarBjorn Helgaas <bhelgaas@google.com>
      468ff15a
  26. 22 Sep, 2014 1 commit
  27. 11 Jun, 2014 2 commits
  28. 28 May, 2014 1 commit
    • Alex Williamson's avatar
      PCI: Introduce new device binding path using pci_dev.driver_override · 782a985d
      Alex Williamson authored
      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/0000:03:00.0/driver_override
        echo 0000:03:00.0 > /sys/bus/pci/devices/0000:03:00.0/driver/unbind
        echo 0000: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/0000:03:00.0/driver_override
        echo 0000:03:00.0 > /sys/bus/pci/devices/0000:03:00.0/driver/unbind
        echo 0000: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's avatarAlex Williamson <alex.williamson@redhat.com>
      Signed-off-by: default avatarBjorn Helgaas <bhelgaas@google.com>
      Reviewed-by: default avatarKonrad Rzeszutek Wilk <konrad.wilk@oracle.com>
      Reviewed-by: default avatarAlexander Graf <agraf@suse.de>
      Acked-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      782a985d
  29. 22 May, 2014 1 commit
  30. 30 Apr, 2014 1 commit