1. 15 1月, 2014 1 次提交
    • A
      PCI: Add pci_try_reset_function(), pci_try_reset_slot(), pci_try_reset_bus() · 61cf16d8
      Alex Williamson 提交于
      When doing a function/slot/bus reset PCI grabs the device_lock for each
      device to block things like suspend and driver probes, but call paths exist
      where this lock may already be held.  This creates an opportunity for
      deadlock.  For instance, vfio allows userspace to issue resets so long as
      it owns the device(s).  If a driver unbind .remove callback races with
      userspace issuing a reset, we have a deadlock as userspace gets stuck
      waiting on device_lock while another thread has device_lock and waits for
      .remove to complete.  To resolve this, we can make a version of the reset
      interfaces which use trylock.  With this, we can safely attempt a reset and
      return error to userspace if there is contention.
      
      [bhelgaas: the deadlock happens when A (userspace) has a file descriptor for
      the device, and B waits in this path:
      
        driver_detach
          device_lock                     # take device_lock
          __device_release_driver
            pci_device_remove             # pci_bus_type.remove
              vfio_pci_remove             # pci_driver .remove
                vfio_del_group_dev
                  wait_event(vfio.release_q, !vfio_dev_present)   # wait (holding device_lock)
      
      Now B is stuck until A gives up the file descriptor.  If A tries to acquire
      device_lock for any reason, we deadlock because A is waiting for B to release
      the lock, and B is waiting for A to release the file descriptor.]
      Signed-off-by: NAlex Williamson <alex.williamson@redhat.com>
      Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
      61cf16d8
  2. 14 1月, 2014 8 次提交
  3. 11 1月, 2014 3 次提交
  4. 08 1月, 2014 1 次提交
    • Y
      PCI: Enforce bus address limits in resource allocation · f75b99d5
      Yinghai Lu 提交于
      When allocating space for 32-bit BARs, we previously limited RESOURCE
      addresses so they would fit in 32 bits.  However, the BUS address need not
      be the same as the resource address, and it's the bus address that must fit
      in the 32-bit BAR.
      
      This patch adds:
      
        - pci_clip_resource_to_region(), which clips a resource so it contains
          only the range that maps to the specified bus address region, e.g., to
          clip a resource to 32-bit bus addresses, and
      
        - pci_bus_alloc_from_region(), which allocates space for a resource from
          the specified bus address region,
      
      and changes pci_bus_alloc_resource() to allocate space for 64-bit BARs from
      the entire bus address region, and space for 32-bit BARs from only the bus
      address region below 4GB.
      
      If we had this window:
      
        pci_root HWP0002:0a: host bridge window [mem 0xf0180000000-0xf01fedfffff] (bus address [0x80000000-0xfedfffff])
      
      we previously could not put a 32-bit BAR there, because the CPU addresses
      don't fit in 32 bits.  This patch fixes this, so we can use this space for
      32-bit BARs.
      
      It's also possible (though unlikely) to have resources with 32-bit CPU
      addresses but bus addresses above 4GB.  In this case the previous code
      would allocate space that a 32-bit BAR could not map.
      
      Remove PCIBIOS_MAX_MEM_32, which is no longer used.
      
      [bhelgaas: reworked starting from http://lkml.kernel.org/r/1386658484-15774-3-git-send-email-yinghai@kernel.org]
      Signed-off-by: NYinghai Lu <yinghai@kernel.org>
      Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
      f75b99d5
  5. 04 1月, 2014 4 次提交
  6. 22 12月, 2013 2 次提交
    • B
      PCI: Add pci_bus_address() to get bus address of a BAR · 06cf56e4
      Bjorn Helgaas 提交于
      We store BAR information as a struct resource, which contains the CPU
      address, not the bus address.  Drivers often need the bus address, and
      there's currently no convenient way to get it, so they often read the
      BAR directly, or use the resource address (which doesn't work if there's
      any translation between CPU and bus addresses).
      
      Add pci_bus_address() to make this convenient.
      Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
      06cf56e4
    • Y
      PCI: Convert pcibios_resource_to_bus() to take a pci_bus, not a pci_dev · fc279850
      Yinghai Lu 提交于
      These interfaces:
      
        pcibios_resource_to_bus(struct pci_dev *dev, *bus_region, *resource)
        pcibios_bus_to_resource(struct pci_dev *dev, *resource, *bus_region)
      
      took a pci_dev, but they really depend only on the pci_bus.  And we want to
      use them in resource allocation paths where we have the bus but not a
      device, so this patch converts them to take the pci_bus instead of the
      pci_dev:
      
        pcibios_resource_to_bus(struct pci_bus *bus, *bus_region, *resource)
        pcibios_bus_to_resource(struct pci_bus *bus, *resource, *bus_region)
      
      In fact, with standard PCI-PCI bridges, they only depend on the host
      bridge, because that's the only place address translation occurs, but
      we aren't going that far yet.
      
      [bhelgaas: changelog]
      Signed-off-by: NYinghai Lu <yinghai@kernel.org>
      Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
      fc279850
  7. 21 12月, 2013 3 次提交
  8. 20 12月, 2013 1 次提交
  9. 18 12月, 2013 3 次提交
  10. 14 12月, 2013 1 次提交
  11. 03 12月, 2013 1 次提交
  12. 26 11月, 2013 1 次提交
  13. 15 11月, 2013 1 次提交
  14. 08 11月, 2013 1 次提交
  15. 26 9月, 2013 3 次提交
  16. 23 8月, 2013 2 次提交
  17. 16 8月, 2013 1 次提交
  18. 15 8月, 2013 1 次提交
    • A
      PCI: Add pci_reset_slot() and pci_reset_bus() · 090a3c53
      Alex Williamson 提交于
      Sometimes pci_reset_function() is not sufficient.  We have cases where
      devices do not support any kind of reset, but there might be multiple
      functions on the bus preventing pci_reset_function() from doing a
      secondary bus reset.  We also have cases where a device will advertise
      that it supports a PM reset, but really does nothing on D3hot->D0
      (graphics cards are notorious for this).  These devices often also
      have more than one function, so even blacklisting PM reset for them
      wouldn't allow a secondary bus reset through pci_reset_function().
      
      If a driver supports multiple devices it should have the ability to
      induce a bus reset when it needs to.  This patch provides that ability
      through pci_reset_slot() and pci_reset_bus().  It's the caller's
      responsibility when using these interfaces to understand that all of
      the devices in or below the slot (or on or below the bus) will be
      reset and therefore should be under control of the caller.  PCI state
      of all the affected devices is saved and restored around these resets,
      but internal state of all of the affected devices is reset (which
      should be the intention).
      Signed-off-by: NAlex Williamson <alex.williamson@redhat.com>
      Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
      090a3c53
  19. 13 8月, 2013 1 次提交
  20. 12 8月, 2013 1 次提交