1. 20 Oct, 2018 1 commit
  2. 10 Oct, 2018 1 commit
    • Singh, Brijesh's avatar
      iommu/amd: Clear memory encryption mask from physical address · 06f93e40
      Singh, Brijesh authored
      commit b3e9b515 upstream.
      Boris Ostrovsky reported a memory leak with device passthrough when SME
      is active.
      The VFIO driver uses iommu_iova_to_phys() to get the physical address for
      an iova. This physical address is later passed into vfio_unmap_unpin() to
      unpin the memory. The vfio_unmap_unpin() uses pfn_valid() before unpinning
      the memory. The pfn_valid() check was failing because encryption mask was
      part of the physical address returned. This resulted in the memory not
      being unpinned and therefore leaked after the guest terminates.
      The memory encryption mask must be cleared from the physical address in
      Fixes: 2543a786
       ("iommu/amd: Allow the AMD IOMMU to work with memory encryption")
      Reported-by: default avatarBoris Ostrovsky <boris.ostrovsky@oracle.com>
      Cc: Tom Lendacky <thomas.lendacky@amd.com>
      Cc: Joerg Roedel <joro@8bytes.org>
      Cc: <iommu@lists.linux-foundation.org>
      Cc: Borislav Petkov <bp@suse.de>
      Cc: Paolo Bonzini <pbonzini@redhat.com>
      Cc: Radim Krčmář <rkrcmar@redhat.com>
      Cc: kvm@vger.kernel.org
      Cc: Boris Ostrovsky <boris.ostrovsky@oracle.com>
      Cc: <stable@vger.kernel.org> # 4.14+
      Signed-off-by: default avatarBrijesh Singh <brijesh.singh@amd.com>
      Signed-off-by: default avatarJoerg Roedel <jroedel@suse.de>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
  3. 04 Oct, 2018 1 commit
  4. 30 May, 2018 1 commit
  5. 20 Dec, 2017 1 commit
  6. 13 Oct, 2017 1 commit
  7. 10 Oct, 2017 1 commit
    • Tom Lendacky's avatar
      iommu/amd: Do not disable SWIOTLB if SME is active · aba2d9a6
      Tom Lendacky authored
      When SME memory encryption is active it will rely on SWIOTLB to handle
      DMA for devices that cannot support the addressing requirements of
      having the encryption mask set in the physical address.  The IOMMU
      currently disables SWIOTLB if it is not running in passthrough mode.
      This is not desired as non-PCI devices attempting DMA may fail. Update
      the code to check if SME is active and not disable SWIOTLB.
      Fixes: 2543a786
       ("iommu/amd: Allow the AMD IOMMU to work with memory encryption")
      Signed-off-by: default avatarTom Lendacky <thomas.lendacky@amd.com>
      Signed-off-by: default avatarJoerg Roedel <jroedel@suse.de>
  8. 28 Aug, 2017 2 commits
  9. 15 Aug, 2017 7 commits
  10. 25 Jul, 2017 1 commit
  11. 18 Jul, 2017 1 commit
    • Tom Lendacky's avatar
      iommu/amd: Allow the AMD IOMMU to work with memory encryption · 2543a786
      Tom Lendacky authored
      The IOMMU is programmed with physical addresses for the various tables
      and buffers that are used to communicate between the device and the
      driver. When the driver allocates this memory it is encrypted. In order
      for the IOMMU to access the memory as encrypted the encryption mask needs
      to be included in these physical addresses during configuration.
      The PTE entries created by the IOMMU should also include the encryption
      mask so that when the device behind the IOMMU performs a DMA, the DMA
      will be performed to encrypted memory.
      Signed-off-by: default avatarTom Lendacky <thomas.lendacky@amd.com>
      Reviewed-by: default avatarThomas Gleixner <tglx@linutronix.de>
      Reviewed-by: default avatarBorislav Petkov <bp@suse.de>
      Acked-by: default avatarJoerg Roedel <jroedel@suse.de>
      Cc: <iommu@lists.linux-foundation.org>
      Cc: Alexander Potapenko <glider@google.com>
      Cc: Andrey Ryabinin <aryabinin@virtuozzo.com>
      Cc: Andy Lutomirski <luto@kernel.org>
      Cc: Arnd Bergmann <arnd@arndb.de>
      Cc: Borislav Petkov <bp@alien8.de>
      Cc: Brijesh Singh <brijesh.singh@amd.com>
      Cc: Dave Young <dyoung@redhat.com>
      Cc: Dmitry Vyukov <dvyukov@google.com>
      Cc: Jonathan Corbet <corbet@lwn.net>
      Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
      Cc: Larry Woodman <lwoodman@redhat.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Matt Fleming <matt@codeblueprint.co.uk>
      Cc: Michael S. Tsirkin <mst@redhat.com>
      Cc: Paolo Bonzini <pbonzini@redhat.com>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Radim Krčmář <rkrcmar@redhat.com>
      Cc: Rik van Riel <riel@redhat.com>
      Cc: Toshimitsu Kani <toshi.kani@hpe.com>
      Cc: kasan-dev@googlegroups.com
      Cc: kvm@vger.kernel.org
      Cc: linux-arch@vger.kernel.org
      Cc: linux-doc@vger.kernel.org
      Cc: linux-efi@vger.kernel.org
      Cc: linux-mm@kvack.org
      Link: http://lkml.kernel.org/r/3053631ea25ba8b1601c351cb7c541c496f6d9bc.1500319216.git.thomas.lendacky@amd.com
      Signed-off-by: default avatarIngo Molnar <mingo@kernel.org>
  12. 28 Jun, 2017 3 commits
  13. 22 Jun, 2017 3 commits
  14. 16 Jun, 2017 1 commit
  15. 08 Jun, 2017 9 commits
  16. 30 May, 2017 2 commits
  17. 30 Mar, 2017 1 commit
  18. 22 Mar, 2017 1 commit
    • Robin Murphy's avatar
      iommu: Disambiguate MSI region types · 9d3a4de4
      Robin Murphy authored
      The introduction of reserved regions has left a couple of rough edges
      which we could do with sorting out sooner rather than later. Since we
      are not yet addressing the potential dynamic aspect of software-managed
      reservations and presenting them at arbitrary fixed addresses, it is
      incongruous that we end up displaying hardware vs. software-managed MSI
      regions to userspace differently, especially since ARM-based systems may
      actually require one or the other, or even potentially both at once,
      (which iommu-dma currently has no hope of dealing with at all). Let's
      resolve the former user-visible inconsistency ASAP before the ABI has
      been baked into a kernel release, in a way that also lays the groundwork
      for the latter shortcoming to be addressed by follow-up patches.
      For clarity, rename the software-managed type to IOMMU_RESV_SW_MSI, use
      IOMMU_RESV_MSI to describe the hardware type, and document everything a
      little bit. Since the x86 MSI remapping hardware falls squarely under
      this meaning of IOMMU_RESV_MSI, apply that type to their regions as well,
      so that we tell the same story to userspace across all platforms.
      Secondly, as the various region types require quite different handling,
      and it really makes little sense to ever try combining them, convert the
      bitfield-esque #defines to a plain enum in the process before anyone
      gets the wrong impression.
      Fixes: d30ddcaa
       ("iommu: Add a new type field in iommu_resv_region")
      Reviewed-by: default avatarEric Auger <eric.auger@redhat.com>
      CC: Alex Williamson <alex.williamson@redhat.com>
      CC: David Woodhouse <dwmw2@infradead.org>
      CC: kvm@vger.kernel.org
      Signed-off-by: default avatarRobin Murphy <robin.murphy@arm.com>
      Signed-off-by: default avatarJoerg Roedel <jroedel@suse.de>
  19. 25 Feb, 2017 1 commit
  20. 10 Feb, 2017 1 commit