1. 17 3月, 2015 2 次提交
  2. 12 3月, 2015 1 次提交
  3. 11 2月, 2015 2 次提交
  4. 08 1月, 2015 1 次提交
  5. 23 11月, 2014 1 次提交
  6. 08 11月, 2014 1 次提交
  7. 30 9月, 2014 2 次提交
    • A
      vfio-pci: Fix remove path locking · 93899a67
      Alex Williamson 提交于
      Locking both the remove() and release() path results in a deadlock
      that should have been obvious.  To fix this we can get and hold the
      vfio_device reference as we evaluate whether to do a bus/slot reset.
      This will automatically block any remove() calls, allowing us to
      remove the explict lock.  Fixes 61d79256.
      Signed-off-by: NAlex Williamson <alex.williamson@redhat.com>
      Cc: stable@vger.kernel.org	[3.17]
      93899a67
    • G
      vfio/pci: Restore MSIx message prior to enabling · b8f02af0
      Gavin Shan 提交于
      The MSIx vector table lives in device memory, which may be cleared as
      part of a backdoor device reset. This is the case on the IBM IPR HBA
      when the BIST is run on the device. When assigned to a QEMU guest,
      the guest driver does a pci_save_state(), issues a BIST, then does a
      pci_restore_state(). The BIST clears the MSIx vector table, but due
      to the way interrupts are configured the pci_restore_state() does not
      restore the vector table as expected. Eventually this results in an
      EEH error on Power platforms when the device attempts to signal an
      interrupt with the zero'd table entry.
      
      Fix the problem by restoring the host cached MSI message prior to
      enabling each vector.
      Reported-by: NWen Xiong <wenxiong@linux.vnet.ibm.com>
      Signed-off-by: NGavin Shan <gwshan@linux.vnet.ibm.com>
      Signed-off-by: NAlex Williamson <alex.williamson@redhat.com>
      b8f02af0
  8. 25 9月, 2014 1 次提交
  9. 09 8月, 2014 1 次提交
  10. 08 8月, 2014 3 次提交
    • A
      vfio-pci: Attempt bus/slot reset on release · bc4fba77
      Alex Williamson 提交于
      Each time a device is released, mark whether a local reset was
      successful or whether a bus/slot reset is needed.  If a reset is
      needed and all of the affected devices are bound to vfio-pci and
      unused, allow the reset.  This is most useful when the userspace
      driver is killed and releases all the devices in an unclean state,
      such as when a QEMU VM quits.
      Signed-off-by: NAlex Williamson <alex.williamson@redhat.com>
      bc4fba77
    • A
      vfio-pci: Use mutex around open, release, and remove · 61d79256
      Alex Williamson 提交于
      Serializing open/release allows us to fix a refcnt error if we fail
      to enable the device and lets us prevent devices from being unbound
      or opened, giving us an opportunity to do bus resets on release.  No
      restriction added to serialize binding devices to vfio-pci while the
      mutex is held though.
      Signed-off-by: NAlex Williamson <alex.williamson@redhat.com>
      61d79256
    • A
      vfio-pci: Release devices with BusMaster disabled · 9c22e660
      Alex Williamson 提交于
      Our current open/release path looks like this:
      
      vfio_pci_open
        vfio_pci_enable
          pci_enable_device
          pci_save_state
          pci_store_saved_state
      
      vfio_pci_release
        vfio_pci_disable
          pci_disable_device
          pci_restore_state
      
      pci_enable_device() doesn't modify PCI_COMMAND_MASTER, so if a device
      comes to us with it enabled, it persists through the open and gets
      stored as part of the device saved state.  We then restore that saved
      state when released, which can allow the device to attempt to continue
      to do DMA.  When the group is disconnected from the domain, this will
      get caught by the IOMMU, but if there are other devices in the group,
      the device may continue running and interfere with the user.  Even in
      the former case, IOMMUs don't necessarily behave well and a stream of
      blocked DMA can result in unpleasant behavior on the host.
      
      Explicitly disable Bus Master as we're enabling the device and
      slightly re-work release to make sure that pci_disable_device() is
      the last thing that touches the device.
      Signed-off-by: NAlex Williamson <alex.williamson@redhat.com>
      9c22e660
  11. 05 8月, 2014 1 次提交
  12. 31 5月, 2014 3 次提交
  13. 15 2月, 2014 1 次提交
  14. 16 1月, 2014 1 次提交
    • A
      vfio-pci: Use pci "try" reset interface · 890ed578
      Alex Williamson 提交于
      PCI resets will attempt to take the device_lock for any device to be
      reset.  This is a problem if that lock is already held, for instance
      in the device remove path.  It's not sufficient to simply kill the
      user process or skip the reset if called after .remove as a race could
      result in the same deadlock.  Instead, we handle all resets as "best
      effort" using the PCI "try" reset interfaces.  This prevents the user
      from being able to induce a deadlock by triggering a reset.
      Signed-off-by: NAlex Williamson <alex.williamson@redhat.com>
      Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
      890ed578
  15. 15 1月, 2014 1 次提交
  16. 18 12月, 2013 1 次提交
  17. 05 9月, 2013 2 次提交
    • A
      vfio-pci: PCI hot reset interface · 8b27ee60
      Alex Williamson 提交于
      The current VFIO_DEVICE_RESET interface only maps to PCI use cases
      where we can isolate the reset to the individual PCI function.  This
      means the device must support FLR (PCIe or AF), PM reset on D3hot->D0
      transition, device specific reset, or be a singleton device on a bus
      for a secondary bus reset.  FLR does not have widespread support,
      PM reset is not very reliable, and bus topology is dictated by the
      system and device design.  We need to provide a means for a user to
      induce a bus reset in cases where the existing mechanisms are not
      available or not reliable.
      
      This device specific extension to VFIO provides the user with this
      ability.  Two new ioctls are introduced:
       - VFIO_DEVICE_PCI_GET_HOT_RESET_INFO
       - VFIO_DEVICE_PCI_HOT_RESET
      
      The first provides the user with information about the extent of
      devices affected by a hot reset.  This is essentially a list of
      devices and the IOMMU groups they belong to.  The user may then
      initiate a hot reset by calling the second ioctl.  We must be
      careful that the user has ownership of all the affected devices
      found via the first ioctl, so the second ioctl takes a list of file
      descriptors for the VFIO groups affected by the reset.  Each group
      must have IOMMU protection established for the ioctl to succeed.
      Signed-off-by: NAlex Williamson <alex.williamson@redhat.com>
      8b27ee60
    • A
      vfio-pci: Test for extended config space · 17638db1
      Alex Williamson 提交于
      Having PCIe/PCI-X capability isn't enough to assume that there are
      extended capabilities.  Both specs define that the first capability
      header is all zero if there are no extended capabilities.  Testing
      for this avoids an erroneous message about hiding capability 0x0 at
      offset 0x100.
      Signed-off-by: NAlex Williamson <alex.williamson@redhat.com>
      17638db1
  18. 28 8月, 2013 1 次提交
    • A
      vfio-pci: Use fdget() rather than eventfd_fget() · 20e77457
      Alex Williamson 提交于
      eventfd_fget() tests to see whether the file is an eventfd file, which
      we then immediately pass to eventfd_ctx_fileget(), which again tests
      whether the file is an eventfd file.  Simplify slightly by using
      fdget() so that we only test that we're looking at an eventfd once.
      fget() could also be used, but fdget() makes use of fget_light() for
      another slight optimization.
      Signed-off-by: NAlex Williamson <alex.williamson@redhat.com>
      20e77457
  19. 25 7月, 2013 1 次提交
    • A
      vfio-pci: Avoid deadlock on remove · d24cdbfd
      Alex Williamson 提交于
      If an attempt is made to unbind a device from vfio-pci while that
      device is in use, the request is blocked until the device becomes
      unused.  Unfortunately, that unbind path still grabs the device_lock,
      which certain things like __pci_reset_function() also want to take.
      This means we need to try to acquire the locks ourselves and use the
      pre-locked version, __pci_reset_function_locked().
      Signed-off-by: NAlex Williamson <alex.williamson@redhat.com>
      d24cdbfd
  20. 29 6月, 2013 1 次提交
  21. 25 4月, 2013 2 次提交
  22. 15 4月, 2013 1 次提交
  23. 01 4月, 2013 2 次提交
  24. 27 3月, 2013 1 次提交
  25. 26 3月, 2013 1 次提交
  26. 16 3月, 2013 1 次提交
  27. 11 3月, 2013 1 次提交
  28. 25 2月, 2013 1 次提交
  29. 19 2月, 2013 2 次提交
    • A
      vfio-pci: Add support for VGA region access · 84237a82
      Alex Williamson 提交于
      PCI defines display class VGA regions at I/O port address 0x3b0, 0x3c0
      and MMIO address 0xa0000.  As these are non-overlapping, we can ignore
      the I/O port vs MMIO difference and expose them both in a single
      region.  We make use of the VGA arbiter around each access to
      configure chipset access as necessary.
      Signed-off-by: NAlex Williamson <alex.williamson@redhat.com>
      84237a82
    • A
      vfio-pci: Manage user power state transitions · 2dd11948
      Alex Williamson 提交于
      We give the user access to change the power state of the device but
      certain transitions result in an uninitialized state which the user
      cannot resolve.  To fix this we need to mark the PowerState field of
      the PMCSR register read-only and effect the requested change on behalf
      of the user.  This has the added benefit that pdev->current_state
      remains accurate while controlled by the user.
      
      The primary example of this bug is a QEMU guest doing a reboot where
      the device it put into D3 on shutdown and becomes unusable on the next
      boot because the device did a soft reset on D3->D0 (NoSoftRst-).
      Signed-off-by: NAlex Williamson <alex.williamson@redhat.com>
      2dd11948