1. 23 Aug, 2019 1 commit
  2. 23 Jul, 2019 1 commit
  3. 01 Jul, 2019 3 commits
    • Kevin Mitchell's avatar
      iommu/amd: Only free resources once on init error · 5c90501a
      Kevin Mitchell authored
      
      
      When amd_iommu=off was specified on the command line, free_X_resources
      functions were called immediately after early_amd_iommu_init. They were
      then called again when amd_iommu_init also failed (as expected).
      
      Instead, call them only once: at the end of state_next() whenever
      there's an error. These functions should be safe to call any time and
      any number of times. However, since state_next is never called again in
      an error state, the cleanup will only ever be run once.
      
      This also ensures that cleanup code is run as soon as possible after an
      error is detected rather than waiting for amd_iommu_init() to be called.
      Signed-off-by: default avatarKevin Mitchell <kevmitch@arista.com>
      Signed-off-by: default avatarJoerg Roedel <jroedel@suse.de>
      5c90501a
    • Kevin Mitchell's avatar
      iommu/amd: Move gart fallback to amd_iommu_init · bf4bff46
      Kevin Mitchell authored
      
      
      The fallback to the GART driver in the case amd_iommu doesn't work was
      executed in a function called free_iommu_resources, which didn't really
      make sense. This was even being called twice if amd_iommu=off was
      specified on the command line.
      
      The only complication is that it needs to be verified that amd_iommu has
      fully relinquished control by calling free_iommu_resources and emptying
      the amd_iommu_list.
      Signed-off-by: default avatarKevin Mitchell <kevmitch@arista.com>
      Signed-off-by: default avatarJoerg Roedel <jroedel@suse.de>
      bf4bff46
    • Kevin Mitchell's avatar
      iommu/amd: Make iommu_disable safer · 3ddbe913
      Kevin Mitchell authored
      Make it safe to call iommu_disable during early init error conditions
      before mmio_base is set, but after the struct amd_iommu has been added
      to the amd_iommu_list. For example, this happens if firmware fails to
      fill in mmio_phys in the ACPI table leading to a NULL pointer
      dereference in iommu_feature_disable.
      
      Fixes: 2c0ae172
      
       ('iommu/amd: Convert iommu initialization to state machine')
      Signed-off-by: default avatarKevin Mitchell <kevmitch@arista.com>
      Signed-off-by: default avatarJoerg Roedel <jroedel@suse.de>
      3ddbe913
  4. 05 Jun, 2019 1 commit
  5. 26 Apr, 2019 1 commit
  6. 12 Apr, 2019 1 commit
    • Joerg Roedel's avatar
      iommu/amd: Set exclusion range correctly · 3c677d20
      Joerg Roedel authored
      The exlcusion range limit register needs to contain the
      base-address of the last page that is part of the range, as
      bits 0-11 of this register are treated as 0xfff by the
      hardware for comparisons.
      
      So correctly set the exclusion range in the hardware to the
      last page which is _in_ the range.
      
      Fixes: b2026aa2
      
       ('x86, AMD IOMMU: add functions for programming IOMMU MMIO space')
      Signed-off-by: default avatarJoerg Roedel <jroedel@suse.de>
      3c677d20
  7. 29 Mar, 2019 1 commit
  8. 11 Feb, 2019 1 commit
  9. 28 Nov, 2018 1 commit
  10. 12 Nov, 2018 1 commit
  11. 06 Oct, 2018 1 commit
  12. 05 Oct, 2018 1 commit
  13. 06 Jul, 2018 3 commits
  14. 13 Feb, 2018 1 commit
  15. 11 Jan, 2018 1 commit
  16. 27 Sep, 2017 1 commit
  17. 19 Aug, 2017 2 commits
  18. 15 Aug, 2017 9 commits
  19. 26 Jul, 2017 1 commit
    • Joerg Roedel's avatar
      iommu/amd: Fix schedule-while-atomic BUG in initialization code · 74ddda71
      Joerg Roedel authored
      
      
      The register_syscore_ops() function takes a mutex and might
      sleep. In the IOMMU initialization code it is invoked during
      irq-remapping setup already, where irqs are disabled.
      
      This causes a schedule-while-atomic bug:
      
       BUG: sleeping function called from invalid context at kernel/locking/mutex.c:747
       in_atomic(): 0, irqs_disabled(): 1, pid: 1, name: swapper/0
       no locks held by swapper/0/1.
       irq event stamp: 304
       hardirqs last  enabled at (303): [<ffffffff818a87b6>] _raw_spin_unlock_irqrestore+0x36/0x60
       hardirqs last disabled at (304): [<ffffffff8235d440>] enable_IR_x2apic+0x79/0x196
       softirqs last  enabled at (36): [<ffffffff818ae75f>] __do_softirq+0x35f/0x4ec
       softirqs last disabled at (31): [<ffffffff810c1955>] irq_exit+0x105/0x120
       CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.13.0-rc2.1.el7a.test.x86_64.debug #1
       Hardware name:          PowerEdge C6145 /040N24, BIOS 3.5.0 10/28/2014
       Call Trace:
        dump_stack+0x85/0xca
        ___might_sleep+0x22a/0x260
        __might_sleep+0x4a/0x80
        __mutex_lock+0x58/0x960
        ? iommu_completion_wait.part.17+0xb5/0x160
        ? register_syscore_ops+0x1d/0x70
        ? iommu_flush_all_caches+0x120/0x150
        mutex_lock_nested+0x1b/0x20
        register_syscore_ops+0x1d/0x70
        state_next+0x119/0x910
        iommu_go_to_state+0x29/0x30
        amd_iommu_enable+0x13/0x23
      
      Fix it by moving the register_syscore_ops() call to the next
      initialization step, which runs with irqs enabled.
      Reported-by: default avatarArtem Savkov <asavkov@redhat.com>
      Tested-by: default avatarArtem Savkov <asavkov@redhat.com>
      Acked-by: default avatarThomas Gleixner <tglx@linutronix.de>
      Fixes: 2c0ae172
      
       ('iommu/amd: Convert iommu initialization to state machine')
      Signed-off-by: default avatarJoerg Roedel <jroedel@suse.de>
      74ddda71
  20. 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>
      2543a786
  21. 22 Jun, 2017 7 commits