1. 21 9月, 2019 1 次提交
    • S
      iommu/amd: Flush old domains in kdump kernel · 52f32e4a
      Stuart Hayes 提交于
      [ Upstream commit 36b7200f67dfe75b416b5281ed4ace9927b513bc ]
      
      When devices are attached to the amd_iommu in a kdump kernel, the old device
      table entries (DTEs), which were copied from the crashed kernel, will be
      overwritten with a new domain number.  When the new DTE is written, the IOMMU
      is told to flush the DTE from its internal cache--but it is not told to flush
      the translation cache entries for the old domain number.
      
      Without this patch, AMD systems using the tg3 network driver fail when kdump
      tries to save the vmcore to a network system, showing network timeouts and
      (sometimes) IOMMU errors in the kernel log.
      
      This patch will flush IOMMU translation cache entries for the old domain when
      a DTE gets overwritten with a new domain number.
      Signed-off-by: NStuart Hayes <stuart.w.hayes@gmail.com>
      Fixes: 3ac3e5ee ('iommu/amd: Copy old trans table from old kernel')
      Signed-off-by: NJoerg Roedel <jroedel@suse.de>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      52f32e4a
  2. 04 5月, 2019 1 次提交
  3. 27 3月, 2019 1 次提交
    • S
      iommu/amd: fix sg->dma_address for sg->offset bigger than PAGE_SIZE · 86915713
      Stanislaw Gruszka 提交于
      commit 4e50ce03976fbc8ae995a000c4b10c737467beaa upstream.
      
      Take into account that sg->offset can be bigger than PAGE_SIZE when
      setting segment sg->dma_address. Otherwise sg->dma_address will point
      at diffrent page, what makes DMA not possible with erros like this:
      
      xhci_hcd 0000:38:00.3: AMD-Vi: Event logged [IO_PAGE_FAULT domain=0x0000 address=0x00000000fdaa70c0 flags=0x0020]
      xhci_hcd 0000:38:00.3: AMD-Vi: Event logged [IO_PAGE_FAULT domain=0x0000 address=0x00000000fdaa7040 flags=0x0020]
      xhci_hcd 0000:38:00.3: AMD-Vi: Event logged [IO_PAGE_FAULT domain=0x0000 address=0x00000000fdaa7080 flags=0x0020]
      xhci_hcd 0000:38:00.3: AMD-Vi: Event logged [IO_PAGE_FAULT domain=0x0000 address=0x00000000fdaa7100 flags=0x0020]
      xhci_hcd 0000:38:00.3: AMD-Vi: Event logged [IO_PAGE_FAULT domain=0x0000 address=0x00000000fdaa7000 flags=0x0020]
      
      Additinally with wrong sg->dma_address unmap_sg will free wrong pages,
      what what can cause crashes like this:
      
      Feb 28 19:27:45 kernel: BUG: Bad page state in process cinnamon  pfn:39e8b1
      Feb 28 19:27:45 kernel: Disabling lock debugging due to kernel taint
      Feb 28 19:27:45 kernel: flags: 0x2ffff0000000000()
      Feb 28 19:27:45 kernel: raw: 02ffff0000000000 0000000000000000 ffffffff00000301 0000000000000000
      Feb 28 19:27:45 kernel: raw: 0000000000000000 0000000000000000 00000001ffffffff 0000000000000000
      Feb 28 19:27:45 kernel: page dumped because: nonzero _refcount
      Feb 28 19:27:45 kernel: Modules linked in: ccm fuse arc4 nct6775 hwmon_vid amdgpu nls_iso8859_1 nls_cp437 edac_mce_amd vfat fat kvm_amd ccp rng_core kvm mt76x0u mt76x0_common mt76x02_usb irqbypass mt76_usb mt76x02_lib mt76 crct10dif_pclmul crc32_pclmul chash mac80211 amd_iommu_v2 ghash_clmulni_intel gpu_sched i2c_algo_bit ttm wmi_bmof snd_hda_codec_realtek snd_hda_codec_generic drm_kms_helper snd_hda_codec_hdmi snd_hda_intel drm snd_hda_codec aesni_intel snd_hda_core snd_hwdep aes_x86_64 crypto_simd snd_pcm cfg80211 cryptd mousedev snd_timer glue_helper pcspkr r8169 input_leds realtek agpgart libphy rfkill snd syscopyarea sysfillrect sysimgblt fb_sys_fops soundcore sp5100_tco k10temp i2c_piix4 wmi evdev gpio_amdpt pinctrl_amd mac_hid pcc_cpufreq acpi_cpufreq sg ip_tables x_tables ext4(E) crc32c_generic(E) crc16(E) mbcache(E) jbd2(E) fscrypto(E) sd_mod(E) hid_generic(E) usbhid(E) hid(E) dm_mod(E) serio_raw(E) atkbd(E) libps2(E) crc32c_intel(E) ahci(E) libahci(E) libata(E) xhci_pci(E) xhci_hcd(E)
      Feb 28 19:27:45 kernel:  scsi_mod(E) i8042(E) serio(E) bcache(E) crc64(E)
      Feb 28 19:27:45 kernel: CPU: 2 PID: 896 Comm: cinnamon Tainted: G    B   W   E     4.20.12-arch1-1-custom #1
      Feb 28 19:27:45 kernel: Hardware name: To Be Filled By O.E.M. To Be Filled By O.E.M./B450M Pro4, BIOS P1.20 06/26/2018
      Feb 28 19:27:45 kernel: Call Trace:
      Feb 28 19:27:45 kernel:  dump_stack+0x5c/0x80
      Feb 28 19:27:45 kernel:  bad_page.cold.29+0x7f/0xb2
      Feb 28 19:27:45 kernel:  __free_pages_ok+0x2c0/0x2d0
      Feb 28 19:27:45 kernel:  skb_release_data+0x96/0x180
      Feb 28 19:27:45 kernel:  __kfree_skb+0xe/0x20
      Feb 28 19:27:45 kernel:  tcp_recvmsg+0x894/0xc60
      Feb 28 19:27:45 kernel:  ? reuse_swap_page+0x120/0x340
      Feb 28 19:27:45 kernel:  ? ptep_set_access_flags+0x23/0x30
      Feb 28 19:27:45 kernel:  inet_recvmsg+0x5b/0x100
      Feb 28 19:27:45 kernel:  __sys_recvfrom+0xc3/0x180
      Feb 28 19:27:45 kernel:  ? handle_mm_fault+0x10a/0x250
      Feb 28 19:27:45 kernel:  ? syscall_trace_enter+0x1d3/0x2d0
      Feb 28 19:27:45 kernel:  ? __audit_syscall_exit+0x22a/0x290
      Feb 28 19:27:45 kernel:  __x64_sys_recvfrom+0x24/0x30
      Feb 28 19:27:45 kernel:  do_syscall_64+0x5b/0x170
      Feb 28 19:27:45 kernel:  entry_SYSCALL_64_after_hwframe+0x44/0xa9
      
      Cc: stable@vger.kernel.org
      Reported-and-tested-by: NJan Viktorin <jan.viktorin@gmail.com>
      Reviewed-by: NAlexander Duyck <alexander.h.duyck@linux.intel.com>
      Signed-off-by: NStanislaw Gruszka <sgruszka@redhat.com>
      Fixes: 80187fd3 ('iommu/amd: Optimize map_sg and unmap_sg')
      Signed-off-by: NJoerg Roedel <jroedel@suse.de>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      86915713
  4. 14 3月, 2019 3 次提交
  5. 13 2月, 2019 1 次提交
    • Y
      iommu/amd: Fix amd_iommu=force_isolation · 3a6f1afa
      Yu Zhao 提交于
      [ Upstream commit c12b08ebbe16f0d3a96a116d86709b04c1ee8e74 ]
      
      The parameter is still there but it's ignored. We need to check its
      value before deciding to go into passthrough mode for AMD IOMMU v2
      capable device.
      
      We occasionally use this parameter to force v2 capable device into
      translation mode to debug memory corruption that we suspect is
      caused by DMA writes.
      
      To address the following comment from Joerg Roedel on the first
      version, v2 capability of device is completely ignored.
      > This breaks the iommu_v2 use-case, as it needs a direct mapping for the
      > devices that support it.
      
      And from Documentation/admin-guide/kernel-parameters.txt:
        This option does not override iommu=pt
      
      Fixes: aafd8ba0 ("iommu/amd: Implement add_device and remove_device")
      Signed-off-by: NYu Zhao <yuzhao@google.com>
      Signed-off-by: NJoerg Roedel <jroedel@suse.de>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      3a6f1afa
  6. 05 10月, 2018 1 次提交
    • S
      iommu/amd: Clear memory encryption mask from physical address · b3e9b515
      Singh, Brijesh 提交于
      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
      iommu_iova_to_phys().
      
      Fixes: 2543a786 ("iommu/amd: Allow the AMD IOMMU to work with memory encryption")
      Reported-by: NBoris 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: NBrijesh Singh <brijesh.singh@amd.com>
      Signed-off-by: NJoerg Roedel <jroedel@suse.de>
      b3e9b515
  7. 26 9月, 2018 1 次提交
  8. 18 8月, 2018 1 次提交
  9. 08 8月, 2018 1 次提交
  10. 20 7月, 2018 1 次提交
    • A
      iommu/amd: Remove redundant WARN_ON() · f1a066fc
      Anna-Maria Gleixner 提交于
      The WARN_ON() was introduced in commit 272e4f99 ("iommu/amd: WARN
      when __[attach|detach]_device are called with irqs enabled") to ensure
      that the domain->lock is taken in proper irqs disabled context. This
      is required, because the domain->lock is taken as well in irq
      context.
      
      The proper context check by the WARN_ON() is redundant, because it is
      already covered by LOCKDEP. When working with locks and changing
      context, a run with LOCKDEP is required anyway and would detect the
      wrong lock context.
      
      Furthermore all callers for those functions are within the same file
      and all callers acquire another lock which already disables interrupts.
      Signed-off-by: NAnna-Maria Gleixner <anna-maria@linutronix.de>
      Signed-off-by: NJoerg Roedel <jroedel@suse.de>
      f1a066fc
  11. 06 7月, 2018 3 次提交
  12. 12 6月, 2018 1 次提交
    • L
      Revert "iommu/amd_iommu: Use CONFIG_DMA_DIRECT_OPS=y and dma_direct_{alloc,free}()" · e16c4790
      Linus Torvalds 提交于
      This reverts commit b468620f.
      
      It turns out that this broke drm on AMD platforms. Quoting Gabriel C:
       "I can confirm reverting b468620f fixes
        that issue for me.
      
        The GPU is working fine with SME enabled.
      
        Now with working GPU :) I can also confirm performance is back to
        normal without doing any other workarounds"
      
      Christan König analyzed it partially:
       "As far as I analyzed it we now get an -ENOMEM from dma_alloc_attrs()
        in drivers/gpu/drm/ttm/ttm_page_alloc_dma.c when IOMMU is enabled"
      
      and Christoph Hellwig responded:
       "I think the prime issue is that dma_direct_alloc respects the dma
        mask. Which we don't need if actually using the iommu. This would be
        mostly harmless exept for the the SEV bit high in the address that
        makes the checks fail.
      
        For now I'd say revert this commit for 4.17/4.18-rc and I'll look into
        addressing these issues properly"
      Reported-and-bisected-by: NGabriel C <nix.or.die@gmail.com>
      Acked-by: NChristoph Hellwig <hch@lst.de>
      Cc: Christian König <christian.koenig@amd.com>
      Cc: Michel Dänzer <michel.daenzer@amd.com>
      Cc: Joerg Roedel <jroedel@suse.de>
      Cc: Tom Lendacky <thomas.lendacky@amd.com>
      Cc: Andrew Morton <akpm@linux-foundation.org>
      Cc: stable@kernel.org		# v4.17
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      e16c4790
  13. 06 6月, 2018 1 次提交
    • T
      irq_remapping: Use apic_ack_irq() · 8a2b7d14
      Thomas Gleixner 提交于
      To address the EBUSY fail of interrupt affinity settings in case that the
      previous setting has not been cleaned up yet, use the new apic_ack_irq()
      function instead of the special ir_ack_apic_edge() implementation which is
      merily a wrapper around ack_APIC_irq().
      
      Preparatory change for the real fix
      
      Fixes: dccfe314 ("x86/vector: Simplify vector move cleanup")
      Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
      Tested-by: NSong Liu <songliubraving@fb.com>
      Cc: Joerg Roedel <jroedel@suse.de>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Song Liu <liu.song.a23@gmail.com>
      Cc: Dmitry Safonov <0x7f454c46@gmail.com>
      Cc: stable@vger.kernel.org
      Cc: Mike Travis <mike.travis@hpe.com>
      Cc: Borislav Petkov <bp@alien8.de>
      Cc: Tariq Toukan <tariqt@mellanox.com>
      Link: https://lkml.kernel.org/r/20180604162224.555716895@linutronix.de
      8a2b7d14
  14. 15 5月, 2018 2 次提交
  15. 11 5月, 2018 1 次提交
    • G
      PCI: Add "pci=noats" boot parameter · cef74409
      Gil Kupfer 提交于
      Adds a "pci=noats" boot parameter.  When supplied, all ATS related
      functions fail immediately and the IOMMU is configured to not use
      device-IOTLB.
      
      Any function that checks for ATS capabilities directly against the devices
      should also check this flag.  Currently, such functions exist only in IOMMU
      drivers, and they are covered by this patch.
      
      The motivation behind this patch is the existence of malicious devices.
      Lots of research has been done about how to use the IOMMU as protection
      from such devices.  When ATS is supported, any I/O device can access any
      physical address by faking device-IOTLB entries.  Adding the ability to
      ignore these entries lets sysadmins enhance system security.
      Signed-off-by: NGil Kupfer <gilkup@cs.technion.ac.il>
      Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
      Acked-by: NJoerg Roedel <jroedel@suse.de>
      cef74409
  16. 03 5月, 2018 3 次提交
  17. 29 3月, 2018 10 次提交
  18. 20 3月, 2018 2 次提交
  19. 15 3月, 2018 2 次提交
  20. 15 2月, 2018 1 次提交
    • S
      iommu/amd: Avoid locking get_irq_table() from atomic context · df42a04b
      Scott Wood 提交于
      get_irq_table() previously acquired amd_iommu_devtable_lock which is not
      a raw lock, and thus cannot be acquired from atomic context on
      PREEMPT_RT.  Many calls to modify_irte*() come from atomic context due to
      the IRQ desc->lock, as does amd_iommu_update_ga() due to the preemption
      disabling in vcpu_load/put().
      
      The only difference between calling get_irq_table() and reading from
      irq_lookup_table[] directly, other than the lock acquisition and
      amd_iommu_rlookup_table[] check, is if the table entry is unpopulated,
      which should never happen when looking up a devid that came from an
      irq_2_irte struct, as get_irq_table() would have already been called on
      that devid during irq_remapping_alloc().
      
      The lock acquisition is not needed in these cases because entries in
      irq_lookup_table[] never change once non-NULL -- nor would the
      amd_iommu_devtable_lock usage in get_irq_table() provide meaningful
      protection if they did, since it's released before using the looked up
      table in the get_irq_table() caller.
      
      Rename the old get_irq_table() to alloc_irq_table(), and create a new
      lockless get_irq_table() to be used in non-allocating contexts that WARNs
      if it doesn't find what it's looking for.
      Signed-off-by: NScott Wood <swood@redhat.com>
      Signed-off-by: NJoerg Roedel <jroedel@suse.de>
      df42a04b
  21. 14 2月, 2018 1 次提交
  22. 13 2月, 2018 1 次提交