linux-stable.git/drivers/vfio, branch linux-3.19.y

vfio-pci: Fix the check on pci device type in vfio_pci_probe()

2015-01-07T17:29:11+00:00

Current vfio-pci just supports normal pci device, so vfio_pci_probe() will
return if the pci device is not a normal device. While current code makes a
mistake. PCI_HEADER_TYPE is the offset in configuration space of the device
type, but we use this value to mask the type value.

This patch fixs this by do the check directly on the pci_dev->hdr_type.

Signed-off-by: Wei Yang 
Signed-off-by: Alex Williamson 
Cc: stable@vger.kernel.org # v3.6+

Merge tag 'vfio-v3.19-rc1' of git://github.com/awilliam/linux-vfio

2014-12-17T18:44:22+00:00

Pull VFIO updates from Alex Williamson:
 - s390 support (Frank Blaschka)
 - Enable iommu-type1 for ARM SMMU (Will Deacon)

* tag 'vfio-v3.19-rc1' of git://github.com/awilliam/linux-vfio:
  drivers/vfio: allow type-1 IOMMU instantiation on top of an ARM SMMU
  vfio: make vfio run on s390

PCI/MSI: Rename write_msi_msg() to pci_write_msi_msg()

2014-11-23T12:01:45+00:00

Rename write_msi_msg() to pci_write_msi_msg() to mark it as PCI
specific.

Signed-off-by: Jiang Liu 
Cc: Bjorn Helgaas 
Cc: Grant Likely 
Cc: Marc Zyngier 
Cc: Yingjoe Chen 
Cc: Yijing Wang 
Signed-off-by: Thomas Gleixner

drivers/vfio: allow type-1 IOMMU instantiation on top of an ARM SMMU

2014-11-14T16:10:59+00:00

The ARM SMMU driver is compatible with the notion of a type-1 IOMMU in
VFIO.

This patch allows VFIO_IOMMU_TYPE1 to be selected if ARM_SMMU=y.

Signed-off-by: Will Deacon 
[aw: update for existing S390 patch]
Signed-off-by: Alex Williamson

vfio: make vfio run on s390

2014-11-07T16:52:22+00:00

add Kconfig switch to hide INTx
add Kconfig switch to let vfio announce PCI BARs are not mapable

Signed-off-by: Frank Blaschka 
Signed-off-by: Alex Williamson

Merge tag 'iommu-updates-v3.18' of git://git.kernel.org/pub/scm/linux/kernel/git/joro/iommu

2014-10-15T05:23:49+00:00

Pull IOMMU updates from Joerg Roedel:
 "This pull-request includes:

   - change in the IOMMU-API to convert the former iommu_domain_capable
     function to just iommu_capable

   - various fixes in handling RMRR ranges for the VT-d driver (one fix
     requires a device driver core change which was acked by Greg KH)

   - the AMD IOMMU driver now assigns and deassigns complete alias
     groups to fix issues with devices using the wrong PCI request-id

   - MMU-401 support for the ARM SMMU driver

   - multi-master IOMMU group support for the ARM SMMU driver

   - various other small fixes all over the place"

* tag 'iommu-updates-v3.18' of git://git.kernel.org/pub/scm/linux/kernel/git/joro/iommu: (41 commits)
  iommu/vt-d: Work around broken RMRR firmware entries
  iommu/vt-d: Store bus information in RMRR PCI device path
  iommu/vt-d: Only remove domain when device is removed
  driver core: Add BUS_NOTIFY_REMOVED_DEVICE event
  iommu/amd: Fix devid mapping for ivrs_ioapic override
  iommu/irq_remapping: Fix the regression of hpet irq remapping
  iommu: Fix bus notifier breakage
  iommu/amd: Split init_iommu_group() from iommu_init_device()
  iommu: Rework iommu_group_get_for_pci_dev()
  iommu: Make of_device_id array const
  amd_iommu: do not dereference a NULL pointer address.
  iommu/omap: Remove omap_iommu unused owner field
  iommu: Remove iommu_domain_has_cap() API function
  IB/usnic: Convert to use new iommu_capable() API function
  vfio: Convert to use new iommu_capable() API function
  kvm: iommu: Convert to use new iommu_capable() API function
  iommu/tegra: Convert to iommu_capable() API function
  iommu/msm: Convert to iommu_capable() API function
  iommu/vt-d: Convert to iommu_capable() API function
  iommu/fsl: Convert to iommu_capable() API function
  ...

Merge tag 'vfio-v3.18-rc1' of git://github.com/awilliam/linux-vfio

2014-10-11T10:49:24+00:00

Pull VFIO updates from Alex Williamson:
 - Nested IOMMU extension to type1 (Will Deacon)
 - Restore MSIx message before enabling (Gavin Shan)
 - Fix remove path locking (Alex Williamson)

* tag 'vfio-v3.18-rc1' of git://github.com/awilliam/linux-vfio:
  vfio-pci: Fix remove path locking
  drivers/vfio: Export vfio_spapr_iommu_eeh_ioctl() with GPL
  vfio/pci: Restore MSIx message prior to enabling
  PCI: Export MSI message relevant functions
  vfio/iommu_type1: add new VFIO_TYPE1_NESTING_IOMMU IOMMU type
  iommu: introduce domain attribute for nesting IOMMUs

vfio-pci: Fix remove path locking

2014-09-29T23:18:39+00:00

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 61d792562b53.

Signed-off-by: Alex Williamson 
Cc: stable@vger.kernel.org	[3.17]

drivers/vfio: Export vfio_spapr_iommu_eeh_ioctl() with GPL

2014-09-29T16:31:51+00:00

The function should have been exported with EXPORT_SYMBOL_GPL()
as part of commit 92d18a6851fb ("drivers/vfio: Fix EEH build error").

Suggested-by: Alexey Kardashevskiy 
Signed-off-by: Gavin Shan 
Signed-off-by: Alex Williamson

vfio/pci: Restore MSIx message prior to enabling

2014-09-29T16:16:24+00:00

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: Wen Xiong 
Signed-off-by: Gavin Shan 
Signed-off-by: Alex Williamson