1. 06 Feb, 2015 2 commits
    • Alex Williamson's avatar
      vfio: Tie IOMMU group reference to vfio group · 4a68810d
      Alex Williamson authored
      Move the iommu_group reference from the device to the vfio_group.
      This ensures that the iommu_group persists as long as the vfio_group
      remains.  This can be important if all of the device from an
      iommu_group are removed, but we still have an outstanding vfio_group
      reference; we can still walk the empty list of devices.
      Signed-off-by: default avatarAlex Williamson <alex.williamson@redhat.com>
    • Alex Williamson's avatar
      vfio: Add device tracking during unbind · 60720a0f
      Alex Williamson authored
      There's a small window between the vfio bus driver calling
      vfio_del_group_dev() and the device being completely unbound where
      the vfio group appears to be non-viable.  This creates a race for
      users like QEMU/KVM where the kvm-vfio module tries to get an
      external reference to the group in order to match and release an
      existing reference, while the device is potentially being removed
      from the vfio bus driver.  If the group is momentarily non-viable,
      kvm-vfio may not be able to release the group reference until VM
      shutdown, making the group unusable until that point.
      Bridge the gap between device removal from the group and completion
      of the driver unbind by tracking it in a list.  The device is added
      to the list before the bus driver reference is released and removed
      using the existing unbind notifier.
      Signed-off-by: default avatarAlex Williamson <alex.williamson@redhat.com>
  2. 27 May, 2014 1 commit
  3. 26 Feb, 2014 1 commit
  4. 19 Dec, 2013 1 commit
  5. 22 Aug, 2013 2 commits
  6. 05 Aug, 2013 1 commit
    • Alexey Kardashevskiy's avatar
      vfio: add external user support · 6cdd9782
      Alexey Kardashevskiy authored
      VFIO is designed to be used via ioctls on file descriptors
      returned by VFIO.
      However in some situations support for an external user is required.
      The first user is KVM on PPC64 (SPAPR TCE protocol) which is going to
      use the existing VFIO groups for exclusive access in real/virtual mode
      on a host to avoid passing map/unmap requests to the user space which
      would made things pretty slow.
      The protocol includes:
      1. do normal VFIO init operation:
      	- opening a new container;
      	- attaching group(s) to it;
      	- setting an IOMMU driver for a container.
      When IOMMU is set for a container, all groups in it are
      considered ready to use by an external user.
      2. User space passes a group fd to an external user.
      The external user calls vfio_group_get_external_user()
      to verify that:
      	- the group is initialized;
      	- IOMMU is set for it.
      If both checks passed, vfio_group_get_external_user()
      increments the container user counter to prevent
      the VFIO group from disposal before KVM exits.
      3. The external user calls vfio_external_user_iommu_id()
      to know an IOMMU ID. PPC64 KVM uses it to link logical bus
      number (LIOBN) with IOMMU ID.
      4. When the external KVM finishes, it calls
      vfio_group_put_external_user() to release the VFIO group.
      This call decrements the container user counter.
      Everything gets released.
      The "vfio: Limit group opens" patch is also required for the consistency.
      Signed-off-by: default avatarAlexey Kardashevskiy <aik@ozlabs.ru>
      Signed-off-by: default avatarAlex Williamson <alex.williamson@redhat.com>
  7. 24 Jul, 2013 2 commits
    • Alex Williamson's avatar
      vfio: Ignore sprurious notifies · c6401930
      Alex Williamson authored
      Remove debugging WARN_ON if we get a spurious notify for a group that
      no longer exists.  No reports of anyone hitting this, but it would
      likely be a race and not a bug if they did.
      Signed-off-by: default avatarAlex Williamson <alex.williamson@redhat.com>
    • Alex Williamson's avatar
      vfio: Don't overreact to DEL_DEVICE · de9c7602
      Alex Williamson authored
      BUS_NOTIFY_DEL_DEVICE triggers IOMMU drivers to remove devices from
      their iommu group, but there's really nothing we can do about it at
      this point.  If the device is in use, then the vfio sub-driver will
      block the device_del from completing until it's released.  If the
      device is not in use or not owned by a vfio sub-driver, then we
      really don't care that it's being removed.
      The current code can be triggered just by unloading an sr-iov driver
      (ex. igb) while the VFs are attached to vfio-pci because it makes an
      incorrect assumption about the ordering of driver remove callbacks
      vs the DEL_DEVICE notification.
      Signed-off-by: default avatarAlex Williamson <alex.williamson@redhat.com>
  8. 25 Jun, 2013 1 commit
    • Alex Williamson's avatar
      vfio: Limit group opens · 6d6768c6
      Alex Williamson authored
      vfio_group_fops_open attempts to limit concurrent sessions by
      disallowing opens once group->container is set.  This really doesn't
      do what we want and allow for inconsistent behavior, for instance a
      group can be opened twice, then a container set giving the user two
      file descriptors to the group.  But then it won't allow more to be
      opened.  There's not much reason to have the group opened multiple
      times since most access is through devices or the container, so
      complete what the original code intended and only allow a single
      Signed-off-by: default avatarAlex Williamson <alex.williamson@redhat.com>
  9. 20 Jun, 2013 1 commit
  10. 05 Jun, 2013 1 commit
  11. 30 Apr, 2013 1 commit
    • Alex Williamson's avatar
      vfio: Set container device mode · 664e9386
      Alex Williamson authored
      Minor 0 is the VFIO container device (/dev/vfio/vfio).  On it's own
      the container does not provide a user with any privileged access.  It
      only supports API version check and extension check ioctls.  Only by
      attaching a VFIO group to the container does it gain any access.  Set
      the mode of the container to allow access.
      Signed-off-by: default avatarAlex Williamson <alex.williamson@redhat.com>
  12. 29 Apr, 2013 1 commit
  13. 25 Apr, 2013 1 commit
  14. 11 Mar, 2013 1 commit
  15. 27 Feb, 2013 1 commit
  16. 14 Feb, 2013 2 commits
    • Alex Williamson's avatar
      vfio: whitelist pcieport · 2b489a45
      Alex Williamson authored
      pcieport does nice things like manage AER and we know it doesn't do
      DMA or expose any user accessible devices on the host.  It also keeps
      the Memory, I/O, and Busmaster bits enabled, which is pretty handy
      when trying to use anyting below it.  Devices owned by pcieport cannot
      be given to users via vfio, but we can tolerate them not being owned
      by vfio-pci.
      Signed-off-by: default avatarAlex Williamson <alex.williamson@redhat.com>
    • Alex Williamson's avatar
      vfio: Protect vfio_dev_present against device_del · e014e944
      Alex Williamson authored
      vfio_dev_present is meant to give us a wait_event callback so that we
      can block removing a device from vfio until it becomes unused.  The
      root of this check depends on being able to get the iommu group from
      the device.  Unfortunately if the BUS_NOTIFY_DEL_DEVICE notifier has
      fired then the device-group reference is no longer searchable and we
      fail the lookup.
      We don't need to go to such extents for this though.  We have a
      reference to the device, from which we can acquire a reference to the
      group.  We can then use the group reference to search for the device
      and properly block removal.
      Signed-off-by: default avatarAlex Williamson <alex.williamson@redhat.com>
  17. 07 Dec, 2012 2 commits
  18. 26 Sep, 2012 2 commits
  19. 22 Aug, 2012 4 commits
  20. 31 Jul, 2012 2 commits
    • Alex Williamson's avatar
      vfio: Type1 IOMMU implementation · 73fa0d10
      Alex Williamson authored
      This VFIO IOMMU backend is designed primarily for AMD-Vi and Intel
      VT-d hardware, but is potentially usable by anything supporting
      similar mapping functionality.  We arbitrarily call this a Type1
      backend for lack of a better name.  This backend has no IOVA
      or host memory mapping restrictions for the user and is optimized
      for relatively static mappings.  Mapped areas are pinned into system
      Signed-off-by: default avatarAlex Williamson <alex.williamson@redhat.com>
    • Alex Williamson's avatar
      vfio: VFIO core · cba3345c
      Alex Williamson authored
      VFIO is a secure user level driver for use with both virtual machines
      and user level drivers.  VFIO makes use of IOMMU groups to ensure the
      isolation of devices in use, allowing unprivileged user access.  It's
      intended that VFIO will replace KVM device assignment and UIO drivers
      (in cases where the target platform includes a sufficiently capable
      New in this version of VFIO is support for IOMMU groups managed
      through the IOMMU core as well as a rework of the API, removing the
      group merge interface.  We now go back to a model more similar to
      original VFIO with UIOMMU support where the file descriptor obtained
      from /dev/vfio/vfio allows access to the IOMMU, but only after a
      group is added, avoiding the previous privilege issues with this type
      of model.  IOMMU support is also now fully modular as IOMMUs have
      vastly different interface requirements on different platforms.  VFIO
      users are able to query and initialize the IOMMU model of their
      Please see the follow-on Documentation commit for further description
      and usage example.
      Signed-off-by: default avatarAlex Williamson <alex.williamson@redhat.com>