1. 17 3月, 2015 15 次提交
  2. 12 3月, 2015 1 次提交
  3. 11 2月, 2015 3 次提交
  4. 07 2月, 2015 5 次提交
    • A
      vfio: Tie IOMMU group reference to vfio group · 4a68810d
      Alex Williamson 提交于
      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: NAlex Williamson <alex.williamson@redhat.com>
      4a68810d
    • A
      vfio: Add device tracking during unbind · 60720a0f
      Alex Williamson 提交于
      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: NAlex Williamson <alex.williamson@redhat.com>
      60720a0f
    • A
      vfio/type1: Add conditional rescheduling · c5e66887
      Alex Williamson 提交于
      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: NAlex Williamson <alex.williamson@redhat.com>
      c5e66887
    • A
      vfio/type1: Chunk contiguous reserved/invalid page mappings · babbf176
      Alex Williamson 提交于
      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: NAlex Williamson <alex.williamson@redhat.com>
      babbf176
    • A
      vfio/type1: DMA unmap chunking · 6fe1010d
      Alex Williamson 提交于
      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: NAlex Williamson <alex.williamson@redhat.com>
      6fe1010d
  5. 08 1月, 2015 1 次提交
  6. 23 11月, 2014 1 次提交
  7. 15 11月, 2014 1 次提交
  8. 08 11月, 2014 1 次提交
  9. 30 9月, 2014 4 次提交
  10. 25 9月, 2014 2 次提交
  11. 09 8月, 2014 3 次提交
    • A
      drivers/vfio: Enable VFIO if EEH is not supported · 9b936c96
      Alexey Kardashevskiy 提交于
      The existing vfio_pci_open() fails upon error returned from
      vfio_spapr_pci_eeh_open(), which breaks POWER7's P5IOC2 PHB
      support which this patch brings back.
      
      The patch fixes the issue by dropping the return value of
      vfio_spapr_pci_eeh_open().
      Signed-off-by: NAlexey Kardashevskiy <aik@ozlabs.ru>
      Signed-off-by: NGavin Shan <gwshan@linux.vnet.ibm.com>
      Signed-off-by: NAlex Williamson <alex.williamson@redhat.com>
      9b936c96
    • A
      drivers/vfio: Allow EEH to be built as module · 89a2edd6
      Alexey Kardashevskiy 提交于
      This adds necessary declarations to the SPAPR VFIO EEH module,
      otherwise multiple dynamic linker errors reported:
      
      vfio_spapr_eeh: Unknown symbol eeh_pe_set_option (err 0)
      vfio_spapr_eeh: Unknown symbol eeh_pe_configure (err 0)
      vfio_spapr_eeh: Unknown symbol eeh_pe_reset (err 0)
      vfio_spapr_eeh: Unknown symbol eeh_pe_get_state (err 0)
      vfio_spapr_eeh: Unknown symbol eeh_iommu_group_to_pe (err 0)
      vfio_spapr_eeh: Unknown symbol eeh_dev_open (err 0)
      vfio_spapr_eeh: Unknown symbol eeh_pe_set_option (err 0)
      vfio_spapr_eeh: Unknown symbol eeh_pe_configure (err 0)
      vfio_spapr_eeh: Unknown symbol eeh_pe_reset (err 0)
      vfio_spapr_eeh: Unknown symbol eeh_pe_get_state (err 0)
      vfio_spapr_eeh: Unknown symbol eeh_iommu_group_to_pe (err 0)
      vfio_spapr_eeh: Unknown symbol eeh_dev_open (err 0)
      Signed-off-by: NAlexey Kardashevskiy <aik@ozlabs.ru>
      Signed-off-by: NGavin Shan <gwshan@linux.vnet.ibm.com>
      Signed-off-by: NAlex Williamson <alex.williamson@redhat.com>
      89a2edd6
    • G
      drivers/vfio: Fix EEH build error · 92d18a68
      Gavin Shan 提交于
      The VFIO related components could be built as dynamic modules.
      Unfortunately, CONFIG_EEH can't be configured to "m". The patch
      fixes the build errors when configuring VFIO related components
      as dynamic modules as follows:
      
        CC [M]  drivers/vfio/vfio_iommu_spapr_tce.o
      In file included from drivers/vfio/vfio.c:33:0:
      include/linux/vfio.h:101:43: warning: ‘struct pci_dev’ declared \
      inside parameter list [enabled by default]
         :
        WRAP    arch/powerpc/boot/zImage.pseries
        WRAP    arch/powerpc/boot/zImage.maple
        WRAP    arch/powerpc/boot/zImage.pmac
        WRAP    arch/powerpc/boot/zImage.epapr
        MODPOST 1818 modules
      ERROR: ".vfio_spapr_iommu_eeh_ioctl" [drivers/vfio/vfio_iommu_spapr_tce.ko]\
      undefined!
      ERROR: ".vfio_spapr_pci_eeh_open" [drivers/vfio/pci/vfio-pci.ko] undefined!
      ERROR: ".vfio_spapr_pci_eeh_release" [drivers/vfio/pci/vfio-pci.ko] undefined!
      Reported-by: NAlexey Kardashevskiy <aik@ozlabs.ru>
      Signed-off-by: NGavin Shan <gwshan@linux.vnet.ibm.com>
      Signed-off-by: NAlexey Kardashevskiy <aik@ozlabs.ru>
      Signed-off-by: NAlex Williamson <alex.williamson@redhat.com>
      92d18a68
  12. 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