1. 07 Apr, 2015 3 commits
    • 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
  2. 17 Mar, 2015 2 commits
  3. 16 Mar, 2015 21 commits
  4. 12 Mar, 2015 1 commit
  5. 10 Feb, 2015 3 commits
  6. 06 Feb, 2015 5 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>
      4a68810d
    • 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>
      60720a0f
    • Alex Williamson's avatar
      vfio/type1: Add conditional rescheduling · c5e66887
      Alex Williamson authored
      
      
      IOMMU operations can be expensive and it's not very difficult for a
      user to give us a lot of work to do for a map or unmap operation.
      Killing a large VM will vfio assigned devices can result in soft
      lockups and IOMMU tracing shows that we can easily spend 80% of our
      time with need-resched set.  A sprinkling of conf_resched() calls
      after map and unmap calls has a very tiny affect on performance
      while resulting in traces with <1% of calls overflowing into needs-
      resched.
      Signed-off-by: default avatarAlex Williamson <alex.williamson@redhat.com>
      c5e66887
    • Alex Williamson's avatar
      vfio/type1: Chunk contiguous reserved/invalid page mappings · babbf176
      Alex Williamson authored
      
      
      We currently map invalid and reserved pages, such as often occur from
      mapping MMIO regions of a VM through the IOMMU, using single pages.
      There's really no reason we can't instead follow the methodology we
      use for normal pages and find the largest possible physically
      contiguous chunk for mapping.  The only difference is that we don't
      do locked memory accounting for these since they're not back by RAM.
      
      In most applications this will be a very minor improvement, but when
      graphics and GPGPU devices are in play, MMIO BARs become non-trivial.
      Signed-off-by: default avatarAlex Williamson <alex.williamson@redhat.com>
      babbf176
    • Alex Williamson's avatar
      vfio/type1: DMA unmap chunking · 6fe1010d
      Alex Williamson authored
      
      
      When unmapping DMA entries we try to rely on the IOMMU API behavior
      that allows the IOMMU to unmap a larger area than requested, up to
      the size of the original mapping.  This works great when the IOMMU
      supports superpages *and* they're in use.  Otherwise, each PAGE_SIZE
      increment is unmapped separately, resulting in poor performance.
      
      Instead we can use the IOVA-to-physical-address translation provided
      by the IOMMU API and unmap using the largest contiguous physical
      memory chunk available, which is also how vfio/type1 would have
      mapped the region.  For a synthetic 1TB guest VM mapping and shutdown
      test on Intel VT-d (2M IOMMU pagesize support), this achieves about
      a 30% overall improvement mapping standard 4K pages, regardless of
      IOMMU superpage enabling, and about a 40% improvement mapping 2M
      hugetlbfs pages when IOMMU superpages are not available.  Hugetlbfs
      with IOMMU superpages enabled is effectively unchanged.
      
      Unfortunately the same algorithm does not work well on IOMMUs with
      fine-grained superpages, like AMD-Vi, costing about 25% extra since
      the IOMMU will automatically unmap any power-of-two contiguous
      mapping we've provided it.  We add a routine and a domain flag to
      detect this feature, leaving AMD-Vi unaffected by this unmap
      optimization.
      Signed-off-by: default avatarAlex Williamson <alex.williamson@redhat.com>
      6fe1010d
  7. 07 Jan, 2015 1 commit
  8. 23 Nov, 2014 1 commit
  9. 14 Nov, 2014 1 commit
  10. 07 Nov, 2014 1 commit
  11. 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