1. 10 Apr, 2017 3 commits
  2. 07 Apr, 2017 1 commit
  3. 28 Mar, 2017 4 commits
  4. 02 Mar, 2017 1 commit
  5. 27 Feb, 2017 7 commits
  6. 25 Feb, 2017 1 commit
  7. 07 Feb, 2017 1 commit
  8. 03 Feb, 2017 1 commit
    • Michael S. Tsirkin's avatar
      Revert "vring: Force use of DMA API for ARM-based systems with legacy devices" · 0d5415b4
      Michael S. Tsirkin authored
      This reverts commit c7070619.
      This has been shown to regress on some ARM systems:
      by forcing on DMA API usage for ARM systems, we have inadvertently
      kicked open a hornets' nest in terms of cache-coherency. Namely that
      unless the virtio device is explicitly described as capable of coherent
      DMA by firmware, the DMA APIs on ARM and other DT-based platforms will
      assume it is non-coherent. This turns out to cause a big problem for the
      likes of QEMU and kvmtool, which generate virtio-mmio devices in their
      guest DTs but neglect to add the often-overlooked "dma-coherent"
      property; as a result, we end up with the guest making non-cacheable
      accesses to the vring, the host doing so cacheably, both talking past
      each other and things going horribly wrong.
      We are working on a safer work-around.
      Fixes: c7070619 ("vring: Force use of DMA API for ARM-based systems with legacy devices")
      Reported-by: default avatarRobin Murphy <robin.murphy@arm.com>
      Cc: <stable@vger.kernel.org>
      Signed-off-by: default avatarWill Deacon <will.deacon@arm.com>
      Signed-off-by: Michael S. Tsirkin's avatarMichael S. Tsirkin <mst@redhat.com>
      Acked-by: default avatarMarc Zyngier <marc.zyngier@arm.com>
  9. 24 Jan, 2017 2 commits
    • Will Deacon's avatar
      vring: Force use of DMA API for ARM-based systems with legacy devices · c7070619
      Will Deacon authored
      Booting Linux on an ARM fastmodel containing an SMMU emulation results
      in an unexpected I/O page fault from the legacy virtio-blk PCI device:
      [    1.211721] arm-smmu-v3 2b400000.smmu: event 0x10 received:
      [    1.211800] arm-smmu-v3 2b400000.smmu:	0x00000000fffff010
      [    1.211880] arm-smmu-v3 2b400000.smmu:	0x0000020800000000
      [    1.211959] arm-smmu-v3 2b400000.smmu:	0x00000008fa081002
      [    1.212075] arm-smmu-v3 2b400000.smmu:	0x0000000000000000
      [    1.212155] arm-smmu-v3 2b400000.smmu: event 0x10 received:
      [    1.212234] arm-smmu-v3 2b400000.smmu:	0x00000000fffff010
      [    1.212314] arm-smmu-v3 2b400000.smmu:	0x0000020800000000
      [    1.212394] arm-smmu-v3 2b400000.smmu:	0x00000008fa081000
      [    1.212471] arm-smmu-v3 2b400000.smmu:	0x0000000000000000
      <system hangs failing to read partition table>
      This is because the legacy virtio-blk device is behind an SMMU, so we
      have consequently swizzled its DMA ops and configured the SMMU to
      translate accesses. This then requires the vring code to use the DMA API
      to establish translations, otherwise all transactions will result in
      fatal faults and termination.
      Given that ARM-based systems only see an SMMU if one is really present
      (the topology is all described by firmware tables such as device-tree or
      IORT), then we can safely use the DMA API for all legacy virtio devices.
      Modern devices can advertise the prescense of an IOMMU using the
      VIRTIO_F_IOMMU_PLATFORM feature flag.
      Cc: Andy Lutomirski <luto@kernel.org>
      Cc: Michael S. Tsirkin <mst@redhat.com>
      Cc: <stable@vger.kernel.org>
      Fixes: 876945db ("arm64: Hook up IOMMU dma_ops")
      Signed-off-by: default avatarWill Deacon <will.deacon@arm.com>
      Signed-off-by: Michael S. Tsirkin's avatarMichael S. Tsirkin <mst@redhat.com>
      Acked-by: default avatarMarc Zyngier <marc.zyngier@arm.com>
    • Robin Murphy's avatar
      virtio_mmio: Set DMA masks appropriately · f7f6634d
      Robin Murphy authored
      Once DMA API usage is enabled, it becomes apparent that virtio-mmio is
      inadvertently relying on the default 32-bit DMA mask, which leads to
      problems like rapidly exhausting SWIOTLB bounce buffers.
      Ensure that we set the appropriate 64-bit DMA mask whenever possible,
      with the coherent mask suitably limited for the legacy vring as per
      a0be1db4 ("virtio_pci: Limit DMA mask to 44 bits for legacy virtio
      Cc: Andy Lutomirski <luto@kernel.org>
      Cc: Michael S. Tsirkin <mst@redhat.com>
      Reported-by: default avatarJean-Philippe Brucker <jean-philippe.brucker@arm.com>
      Fixes: b4211138 ("virtio_mmio: Use the DMA API if enabled")
      Signed-off-by: default avatarRobin Murphy <robin.murphy@arm.com>
      Signed-off-by: Michael S. Tsirkin's avatarMichael S. Tsirkin <mst@redhat.com>
  10. 15 Dec, 2016 9 commits
  11. 30 Oct, 2016 5 commits
  12. 24 Oct, 2016 1 commit
  13. 09 Sep, 2016 1 commit
  14. 09 Aug, 2016 2 commits
  15. 01 Aug, 2016 1 commit
    • Michael S. Tsirkin's avatar
      virtio: new feature to detect IOMMU device quirk · 1a937693
      Michael S. Tsirkin authored
      The interaction between virtio and IOMMUs is messy.
      On most systems with virtio, physical addresses match bus addresses,
      and it doesn't particularly matter which one we use to program
      the device.
      On some systems, including Xen and any system with a physical device
      that speaks virtio behind a physical IOMMU, we must program the IOMMU
      for virtio DMA to work at all.
      On other systems, including SPARC and PPC64, virtio-pci devices are
      enumerated as though they are behind an IOMMU, but the virtio host
      ignores the IOMMU, so we must either pretend that the IOMMU isn't
      there or somehow map everything as the identity.
      Add a feature bit to detect that quirk: VIRTIO_F_IOMMU_PLATFORM.
      Any device with this feature bit set to 0 needs a quirk and has to be
      passed physical addresses (as opposed to bus addresses) even though
      the device is behind an IOMMU.
      Note: it has to be a per-device quirk because for example, there could
      be a mix of passed-through and virtual virtio devices. As another
      example, some devices could be implemented by an out of process
      hypervisor backend (in case of qemu vhost, or vhost-user) and so support
      for an IOMMU needs to be coded up separately.
      It would be cleanest to handle this in IOMMU core code, but that needs
      per-device DMA ops. While we are waiting for that to be implemented, use
      a work-around in virtio core.
      Note: a "noiommu" feature is a quirk - add a wrapper to make
      that clear.
      Signed-off-by: Michael S. Tsirkin's avatarMichael S. Tsirkin <mst@redhat.com>