1. 04 Nov, 2015 1 commit
    • Alex Williamson's avatar
      vfio: Include No-IOMMU mode · 033291ec
      Alex Williamson authored
      
      
      There is really no way to safely give a user full access to a DMA
      capable device without an IOMMU to protect the host system.  There is
      also no way to provide DMA translation, for use cases such as device
      assignment to virtual machines.  However, there are still those users
      that want userspace drivers even under those conditions.  The UIO
      driver exists for this use case, but does not provide the degree of
      device access and programming that VFIO has.  In an effort to avoid
      code duplication, this introduces a No-IOMMU mode for VFIO.
      
      This mode requires building VFIO with CONFIG_VFIO_NOIOMMU and enabling
      the "enable_unsafe_noiommu_mode" option on the vfio driver.  This
      should make it very clear that this mode is not safe.  Additionally,
      CAP_SYS_RAWIO privileges are necessary to work with groups and
      containers using this mode.  Groups making use of this support are
      named /dev/vfio/noiommu-$GROUP and can only make use of the special
      VFIO_NOIOMMU_IOMMU for the container.  Use of this mode, specifically
      binding a device without a native IOMMU group to a VFIO bus driver
      will taint the kernel and should therefore not be considered
      supported.  This patch includes no-iommu support for the vfio-pci bus
      driver only.
      Signed-off-by: default avatarAlex Williamson <alex.williamson@redhat.com>
      Acked-by: default avatarMichael S. Tsirkin <mst@redhat.com>
      033291ec
  2. 09 Jun, 2015 1 commit
    • Alex Williamson's avatar
      vfio/pci: Fix racy vfio_device_get_from_dev() call · 20f30017
      Alex Williamson authored
      
      
      Testing the driver for a PCI device is racy, it can be all but
      complete in the release path and still report the driver as ours.
      Therefore we can't trust drvdata to be valid.  This race can sometimes
      be seen when one port of a multifunction device is being unbound from
      the vfio-pci driver while another function is being released by the
      user and attempting a bus reset.  The device in the remove path is
      found as a dependent device for the bus reset of the release path
      device, the driver is still set to vfio-pci, but the drvdata has
      already been cleared, resulting in a null pointer dereference.
      
      To resolve this, fix vfio_device_get_from_dev() to not take the
      dev_get_drvdata() shortcut and instead traverse through the
      iommu_group, vfio_group, vfio_device path to get a reference we
      can trust.  Once we have that reference, we know the device isn't
      in transition and we can test to make sure the driver is still what
      we expect, so that we don't interfere with devices we don't own.
      Signed-off-by: default avatarAlex Williamson <alex.williamson@redhat.com>
      20f30017
  3. 01 May, 2015 1 commit
  4. 08 Apr, 2015 1 commit
  5. 07 Apr, 2015 5 commits
    • Alex Williamson's avatar
      vfio-pci: Move idle devices to D3hot power state · 6eb70187
      Alex Williamson authored
      
      
      We can save some power by putting devices that are bound to vfio-pci
      but not in use by the user in the D3hot power state.  Devices get
      woken into D0 when opened by the user.  Resets return the device to
      D0, so we need to re-apply the low power state after a bus reset.
      It's tempting to try to use D3cold, but we have no reason to inhibit
      hotplug of idle devices and we might get into a loop of having the
      device disappear before we have a chance to try to use it.
      
      A new module parameter allows this feature to be disabled if there are
      devices that misbehave as a result of this change.
      Signed-off-by: default avatarAlex Williamson <alex.williamson@redhat.com>
      6eb70187
    • Alex Williamson's avatar
      vfio-pci: Remove warning if try-reset fails · 561d72dd
      Alex Williamson authored
      
      
      As indicated in the comment, this is not entirely uncommon and
      causes user concern for no reason.
      Signed-off-by: default avatarAlex Williamson <alex.williamson@redhat.com>
      561d72dd
    • Alex Williamson's avatar
      vfio-pci: Allow PCI IDs to be specified as module options · 80c7e8cc
      Alex Williamson authored
      
      
      This copies the same support from pci-stub for exactly the same
      purpose, enabling a set of PCI IDs to be automatically added to the
      driver's dynamic ID table at module load time.  The code here is
      pretty simple and both vfio-pci and pci-stub are fairly unique in
      being meta drivers, capable of attaching to any device, so there's no
      attempt made to generalize the code into pci-core.
      Signed-off-by: default avatarAlex Williamson <alex.williamson@redhat.com>
      80c7e8cc
    • Alex Williamson's avatar
      vfio-pci: Add VGA arbiter client · ecaa1f6a
      Alex Williamson authored
      
      
      If VFIO VGA access is disabled for the user, either by CONFIG option
      or module parameter, we can often opt-out of VGA arbitration.  We can
      do this when PCI bridge control of VGA routing is possible.  This
      means that we must have a parent bridge and there must only be a
      single VGA device below that bridge.  Fortunately this is the typical
      case for discrete GPUs.
      
      Doing this allows us to minimize the impact of additional GPUs, in
      terms of VGA arbitration, when they are only used via vfio-pci for
      non-VGA applications.
      Signed-off-by: default avatarAlex Williamson <alex.williamson@redhat.com>
      ecaa1f6a
    • Alex Williamson's avatar
      vfio-pci: Add module option to disable VGA region access · 88c0dead
      Alex Williamson authored
      
      
      Add a module option so that we don't require a CONFIG change and
      kernel rebuild to disable VGA support.  Not only can VGA support be
      troublesome in itself, but by disabling it we can reduce the impact
      to host devices by doing a VGA arbitration opt-out.
      Signed-off-by: default avatarAlex Williamson <alex.williamson@redhat.com>
      88c0dead
  6. 16 Mar, 2015 2 commits
  7. 10 Feb, 2015 1 commit
  8. 07 Jan, 2015 1 commit
  9. 07 Nov, 2014 1 commit
  10. 29 Sep, 2014 1 commit
    • Alex Williamson's avatar
      vfio-pci: Fix remove path locking · 93899a67
      Alex Williamson authored
      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: default avatarAlex Williamson <alex.williamson@redhat.com>
      Cc: stable@vger.kernel.org	[3.17]
      93899a67
  11. 08 Aug, 2014 1 commit
  12. 07 Aug, 2014 3 commits
    • Alex Williamson's avatar
      vfio-pci: Attempt bus/slot reset on release · bc4fba77
      Alex Williamson authored
      
      
      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: default avatarAlex Williamson <alex.williamson@redhat.com>
      bc4fba77
    • Alex Williamson's avatar
      vfio-pci: Use mutex around open, release, and remove · 61d79256
      Alex Williamson authored
      
      
      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: default avatarAlex Williamson <alex.williamson@redhat.com>
      61d79256
    • Alex Williamson's avatar
      vfio-pci: Release devices with BusMaster disabled · 9c22e660
      Alex Williamson authored
      
      
      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: default avatarAlex Williamson <alex.williamson@redhat.com>
      9c22e660
  13. 04 Aug, 2014 1 commit
  14. 30 May, 2014 2 commits
  15. 15 Jan, 2014 1 commit
    • Alex Williamson's avatar
      vfio-pci: Use pci "try" reset interface · 890ed578
      Alex Williamson authored
      
      
      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: default avatarAlex Williamson <alex.williamson@redhat.com>
      Signed-off-by: default avatarBjorn Helgaas <bhelgaas@google.com>
      890ed578
  16. 14 Jan, 2014 1 commit
    • Alex Williamson's avatar
      vfio-pci: Don't use device_lock around AER interrupt setup · 3be3a074
      Alex Williamson authored
      
      
      device_lock is much too prone to lockups.  For instance if we have a
      pending .remove then device_lock is already held.  If userspace
      attempts to modify AER signaling after that point, a deadlock occurs.
      eventfd setup/teardown is already protected in vfio with the igate
      mutex.  AER is not a high performance interrupt, so we can also use
      the same mutex to protect signaling versus setup races.
      Signed-off-by: default avatarAlex Williamson <alex.williamson@redhat.com>
      3be3a074
  17. 04 Sep, 2013 1 commit
    • Alex Williamson's avatar
      vfio-pci: PCI hot reset interface · 8b27ee60
      Alex Williamson authored
      
      
      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: default avatarAlex Williamson <alex.williamson@redhat.com>
      8b27ee60
  18. 24 Jul, 2013 1 commit
    • Alex Williamson's avatar
      vfio-pci: Avoid deadlock on remove · d24cdbfd
      Alex Williamson authored
      
      
      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: default avatarAlex Williamson <alex.williamson@redhat.com>
      d24cdbfd
  19. 29 Jun, 2013 1 commit
  20. 24 Apr, 2013 2 commits
  21. 26 Mar, 2013 1 commit
  22. 11 Mar, 2013 1 commit
  23. 18 Feb, 2013 1 commit
  24. 14 Feb, 2013 2 commits
  25. 07 Dec, 2012 4 commits
  26. 10 Oct, 2012 1 commit
  27. 09 Oct, 2012 1 commit
    • Linus Torvalds's avatar
      Fix staging driver use of VM_RESERVED · 547b1e81
      Linus Torvalds authored
      The VM_RESERVED flag was killed off in commit 314e51b9
      
       ("mm: kill
      vma flag VM_RESERVED and mm->reserved_vm counter"), and replaced by the
      proper semantic flags (eg "don't core-dump" etc).  But there was a new
      use of VM_RESERVED that got missed by the merge.
      
      Fix the remaining use of VM_RESERVED in the vfio_pci driver, replacing
      the VM_RESERVED flag with VM_DONTEXPAND | VM_DONTDUMP.
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation,org>
      547b1e81