1. 13 Dec, 2018 1 commit
  2. 22 Feb, 2018 1 commit
  3. 18 Jul, 2017 2 commits
    • Tom Lendacky's avatar
      swiotlb: Add warnings for use of bounce buffers with SME · 648babb7
      Tom Lendacky authored
      Add warnings to let the user know when bounce buffers are being used for
      DMA when SME is active.  Since the bounce buffers are not in encrypted
      memory, these notifications are to allow the user to determine some
      appropriate action - if necessary.  Actions can range from utilizing an
      IOMMU, replacing the device with another device that can support 64-bit
      DMA, ignoring the message if the device isn't used much, etc.
      Signed-off-by: 's avatarTom Lendacky <thomas.lendacky@amd.com>
      Reviewed-by: 's avatarThomas Gleixner <tglx@linutronix.de>
      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/d112564053c3f2e86ca634a8d4fa4abc0eb53a6a.1500319216.git.thomas.lendacky@amd.comSigned-off-by: 's avatarIngo Molnar <mingo@kernel.org>
      648babb7
    • Tom Lendacky's avatar
      x86, swiotlb: Add memory encryption support · c7753208
      Tom Lendacky authored
      Since DMA addresses will effectively look like 48-bit addresses when the
      memory encryption mask is set, SWIOTLB is needed if the DMA mask of the
      device performing the DMA does not support 48-bits. SWIOTLB will be
      initialized to create decrypted bounce buffers for use by these devices.
      Signed-off-by: 's avatarTom Lendacky <thomas.lendacky@amd.com>
      Reviewed-by: 's avatarThomas Gleixner <tglx@linutronix.de>
      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/aa2d29b78ae7d508db8881e46a3215231b9327a7.1500319216.git.thomas.lendacky@amd.comSigned-off-by: 's avatarIngo Molnar <mingo@kernel.org>
      c7753208
  4. 15 Jan, 2017 1 commit
  5. 06 Jan, 2017 1 commit
  6. 19 Dec, 2016 2 commits
  7. 10 Nov, 2016 1 commit
  8. 07 Nov, 2016 3 commits
  9. 04 Aug, 2016 1 commit
    • Krzysztof Kozlowski's avatar
      dma-mapping: use unsigned long for dma_attrs · 00085f1e
      Krzysztof Kozlowski authored
      The dma-mapping core and the implementations do not change the DMA
      attributes passed by pointer.  Thus the pointer can point to const data.
      However the attributes do not have to be a bitfield.  Instead unsigned
      long will do fine:
      
      1. This is just simpler.  Both in terms of reading the code and setting
         attributes.  Instead of initializing local attributes on the stack
         and passing pointer to it to dma_set_attr(), just set the bits.
      
      2. It brings safeness and checking for const correctness because the
         attributes are passed by value.
      
      Semantic patches for this change (at least most of them):
      
          virtual patch
          virtual context
      
          @r@
          identifier f, attrs;
      
          @@
          f(...,
          - struct dma_attrs *attrs
          + unsigned long attrs
          , ...)
          {
          ...
          }
      
          @@
          identifier r.f;
          @@
          f(...,
          - NULL
          + 0
           )
      
      and
      
          // Options: --all-includes
          virtual patch
          virtual context
      
          @r@
          identifier f, attrs;
          type t;
      
          @@
          t f(..., struct dma_attrs *attrs);
      
          @@
          identifier r.f;
          @@
          f(...,
          - NULL
          + 0
           )
      
      Link: http://lkml.kernel.org/r/1468399300-5399-2-git-send-email-k.kozlowski@samsung.comSigned-off-by: 's avatarKrzysztof Kozlowski <k.kozlowski@samsung.com>
      Acked-by: 's avatarVineet Gupta <vgupta@synopsys.com>
      Acked-by: 's avatarRobin Murphy <robin.murphy@arm.com>
      Acked-by: 's avatarHans-Christian Noren Egtvedt <egtvedt@samfundet.no>
      Acked-by: Mark Salter <msalter@redhat.com> [c6x]
      Acked-by: Jesper Nilsson <jesper.nilsson@axis.com> [cris]
      Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch> [drm]
      Reviewed-by: 's avatarBart Van Assche <bart.vanassche@sandisk.com>
      Acked-by: Joerg Roedel <jroedel@suse.de> [iommu]
      Acked-by: Fabien Dessenne <fabien.dessenne@st.com> [bdisp]
      Reviewed-by: Marek Szyprowski <m.szyprowski@samsung.com> [vb2-core]
      Acked-by: David Vrabel <david.vrabel@citrix.com> [xen]
      Acked-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> [xen swiotlb]
      Acked-by: Joerg Roedel <jroedel@suse.de> [iommu]
      Acked-by: Richard Kuo <rkuo@codeaurora.org> [hexagon]
      Acked-by: Geert Uytterhoeven <geert@linux-m68k.org> [m68k]
      Acked-by: Gerald Schaefer <gerald.schaefer@de.ibm.com> [s390]
      Acked-by: 's avatarBjorn Andersson <bjorn.andersson@linaro.org>
      Acked-by: Hans-Christian Noren Egtvedt <egtvedt@samfundet.no> [avr32]
      Acked-by: Vineet Gupta <vgupta@synopsys.com> [arc]
      Acked-by: Robin Murphy <robin.murphy@arm.com> [arm64 and dma-iommu]
      Signed-off-by: 's avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: 's avatarLinus Torvalds <torvalds@linux-foundation.org>
      00085f1e
  10. 11 Jun, 2015 1 commit
  11. 05 Jun, 2015 1 commit
  12. 05 May, 2015 1 commit
  13. 20 Jun, 2014 1 commit
    • Jan Beulich's avatar
      swiotlb: don't assume PA 0 is invalid · 8e0629c1
      Jan Beulich authored
      In 2.6.29 io_tlb_orig_addr[] got converted from storing virtual addresses
      to storing physical ones. While checking virtual addresses against NULL
      is a legitimate thing to catch invalid entries, checking physical ones
      against zero isn't: There's no guarantee that PFN 0 is reserved on a
      particular platform.
      
      Since it is unclear whether the check in swiotlb_tbl_unmap_single() is
      actually needed, retain it but check against a guaranteed invalid physical
      address. This requires setting up the array in a suitable fashion. And
      since the original code failed to invalidate array entries when regions
      get unmapped, this is being fixed at once along with adding a similar
      check to swiotlb_tbl_sync_single().
      
      Obviously the less intrusive change would be to simply drop the check in
      swiotlb_tbl_unmap_single().
      Signed-off-by: 's avatarJan Beulich <jbeulich@suse.com>
      Signed-off-by: 's avatarKonrad Rzeszutek Wilk <konrad.wilk@oracle.com>
      8e0629c1
  14. 04 Jun, 2014 1 commit
    • Akinobu Mita's avatar
      x86: enable DMA CMA with swiotlb · 9c5a3621
      Akinobu Mita authored
      The DMA Contiguous Memory Allocator support on x86 is disabled when
      swiotlb config option is enabled.  So DMA CMA is always disabled on
      x86_64 because swiotlb is always enabled.  This attempts to support for
      DMA CMA with enabling swiotlb config option.
      
      The contiguous memory allocator on x86 is integrated in the function
      dma_generic_alloc_coherent() which is .alloc callback in nommu_dma_ops
      for dma_alloc_coherent().
      
      x86_swiotlb_alloc_coherent() which is .alloc callback in swiotlb_dma_ops
      tries to allocate with dma_generic_alloc_coherent() firstly and then
      swiotlb_alloc_coherent() is called as a fallback.
      
      The main part of supporting DMA CMA with swiotlb is that changing
      x86_swiotlb_free_coherent() which is .free callback in swiotlb_dma_ops
      for dma_free_coherent() so that it can distinguish memory allocated by
      dma_generic_alloc_coherent() from one allocated by
      swiotlb_alloc_coherent() and release it with dma_generic_free_coherent()
      which can handle contiguous memory.  This change requires making
      is_swiotlb_buffer() global function.
      
      This also needs to change .free callback in the dma_map_ops for amd_gart
      and sta2x11, because these dma_ops are also using
      dma_generic_alloc_coherent().
      Signed-off-by: 's avatarAkinobu Mita <akinobu.mita@gmail.com>
      Acked-by: 's avatarMarek Szyprowski <m.szyprowski@samsung.com>
      Acked-by: 's avatarKonrad Rzeszutek Wilk <konrad.wilk@oracle.com>
      Cc: David Woodhouse <dwmw2@infradead.org>
      Cc: Don Dutile <ddutile@redhat.com>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Ingo Molnar <mingo@redhat.com>
      Cc: "H. Peter Anvin" <hpa@zytor.com>
      Cc: Andi Kleen <andi@firstfloor.org>
      Cc: Yinghai Lu <yinghai@kernel.org>
      Signed-off-by: 's avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: 's avatarLinus Torvalds <torvalds@linux-foundation.org>
      9c5a3621
  15. 28 Jan, 2014 1 commit
  16. 22 Jan, 2014 1 commit
    • Santosh Shilimkar's avatar
      lib/swiotlb.c: use memblock apis for early memory allocations · 457ff1de
      Santosh Shilimkar authored
      Switch to memblock interfaces for early memory allocator instead of
      bootmem allocator.  No functional change in beahvior than what it is in
      current code from bootmem users points of view.
      
      Archs already converted to NO_BOOTMEM now directly use memblock
      interfaces instead of bootmem wrappers build on top of memblock.  And
      the archs which still uses bootmem, these new apis just fallback to
      exiting bootmem APIs.
      Signed-off-by: 's avatarSantosh Shilimkar <santosh.shilimkar@ti.com>
      Cc: "Rafael J. Wysocki" <rjw@sisk.pl>
      Cc: Arnd Bergmann <arnd@arndb.de>
      Cc: Christoph Lameter <cl@linux-foundation.org>
      Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
      Cc: Grygorii Strashko <grygorii.strashko@ti.com>
      Cc: H. Peter Anvin <hpa@zytor.com>
      Cc: Johannes Weiner <hannes@cmpxchg.org>
      Cc: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
      Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
      Cc: Michal Hocko <mhocko@suse.cz>
      Cc: Paul Walmsley <paul@pwsan.com>
      Cc: Pavel Machek <pavel@ucw.cz>
      Cc: Russell King <linux@arm.linux.org.uk>
      Cc: Tejun Heo <tj@kernel.org>
      Cc: Tony Lindgren <tony@atomide.com>
      Cc: Yinghai Lu <yinghai@kernel.org>
      Signed-off-by: 's avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: 's avatarLinus Torvalds <torvalds@linux-foundation.org>
      457ff1de
  17. 07 Jan, 2014 1 commit
  18. 25 Oct, 2013 1 commit
  19. 24 Oct, 2013 1 commit
  20. 02 Oct, 2013 1 commit
    • Zoltan Kiss's avatar
      tracing/events: Add bounce tracing to swiotbl · 2b2b614d
      Zoltan Kiss authored
      Ftrace is currently not able to detect when SWIOTLB has to do double buffering.
      Under Xen you can only see it indirectly in function_graph, when
      xen_swiotlb_map_page() doesn't stop after range_straddles_page_boundary(), but
      calls spinlock functions, memcpy() and xen_phys_to_bus() as well. This patch
      introduces the swiotlb:swiotlb_bounced event, which also prints out the
      following informations to help you find out why bouncing happened:
      
      dev_name: 0000:08:00.0 dma_mask=ffffffffffffffff dev_addr=9149f000 size=32768
      swiotlb_force=0
      
      If you use Xen, and (dev_addr + size + 1) > dma_mask, the buffer is out of the
      device's DMA range. If swiotlb_force == 1, you should really change the kernel
      parameters. Otherwise, the buffer is not contiguous in mfn space.
      Signed-off-by: 's avatarZoltan Kiss <zoltan.kiss@citrix.com>
      [v1: Don't print 'swiotlb_force=X', just print swiotlb_force if it is enabled]
      Signed-off-by: 's avatarKonrad Rzeszutek Wilk <konrad.wilk@oracle.com>
      2b2b614d
  21. 09 Aug, 2013 1 commit
  22. 17 Apr, 2013 1 commit
    • Yinghai Lu's avatar
      x86, kdump: Set crashkernel_low automatically · c729de8f
      Yinghai Lu authored
      Chao said that kdump does does work well on his system on 3.8
      without extra parameter, even iommu does not work with kdump.
      And now have to append crashkernel_low=Y in first kernel to make
      kdump work.
      
      We have now modified crashkernel=X to allocate memory beyong 4G (if
      available) and do not allocate low range for crashkernel if the user
      does not specify that with crashkernel_low=Y.  This causes regression
      if iommu is not enabled.  Without iommu, swiotlb needs to be setup in
      first 4G and there is no low memory available to second kernel.
      
      Set crashkernel_low automatically if the user does not specify that.
      
      For system that does support IOMMU with kdump properly, user could
      specify crashkernel_low=0 to save that 72M low ram.
      
      -v3: add swiotlb_size() according to Konrad.
      -v4: add comments what 8M is for according to hpa.
           also update more crashkernel_low= in kernel-parameters.txt
      -v5: update changelog according to Vivek.
      -v6: Change description about swiotlb referring according to HATAYAMA.
      Reported-by: 's avatarWANG Chao <chaowang@redhat.com>
      Tested-by: 's avatarWANG Chao <chaowang@redhat.com>
      Signed-off-by: 's avatarYinghai Lu <yinghai@kernel.org>
      Link: http://lkml.kernel.org/r/1366089828-19692-2-git-send-email-yinghai@kernel.orgAcked-by: 's avatarVivek Goyal <vgoyal@redhat.com>
      Signed-off-by: 's avatarH. Peter Anvin <hpa@linux.intel.com>
      c729de8f
  23. 30 Jan, 2013 1 commit
    • Yinghai Lu's avatar
      x86: Don't panic if can not alloc buffer for swiotlb · ac2cbab2
      Yinghai Lu authored
      Normal boot path on system with iommu support:
      swiotlb buffer will be allocated early at first and then try to initialize
      iommu, if iommu for intel or AMD could setup properly, swiotlb buffer
      will be freed.
      
      The early allocating is with bootmem, and could panic when we try to use
      kdump with buffer above 4G only, or with memmap to limit mem under 4G.
      for example: memmap=4095M$1M to remove memory under 4G.
      
      According to Eric, add _nopanic version and no_iotlb_memory to fail
      map single later if swiotlb is still needed.
      
      -v2: don't pass nopanic, and use -ENOMEM return value according to Eric.
           panic early instead of using swiotlb_full to panic...according to Eric/Konrad.
      -v3: make swiotlb_init to be notpanic, but will affect:
           arm64, ia64, powerpc, tile, unicore32, x86.
      -v4: cleanup swiotlb_init by removing swiotlb_init_with_default_size.
      Suggested-by: 's avatarEric W. Biederman <ebiederm@xmission.com>
      Signed-off-by: 's avatarYinghai Lu <yinghai@kernel.org>
      Link: http://lkml.kernel.org/r/1359058816-7615-36-git-send-email-yinghai@kernel.orgReviewed-and-tested-by: 's avatarKonrad Rzeszutek Wilk <konrad.wilk@oracle.com>
      Cc: Joerg Roedel <joro@8bytes.org>
      Cc: Ralf Baechle <ralf@linux-mips.org>
      Cc: Jeremy Fitzhardinge <jeremy@goop.org>
      Cc: Kyungmin Park <kyungmin.park@samsung.com>
      Cc: Marek Szyprowski <m.szyprowski@samsung.com>
      Cc: Arnd Bergmann <arnd@arndb.de>
      Cc: Andrzej Pietrasiewicz <andrzej.p@samsung.com>
      Cc: linux-mips@linux-mips.org
      Cc: xen-devel@lists.xensource.com
      Cc: virtualization@lists.linux-foundation.org
      Cc: Shuah Khan <shuahkhan@gmail.com>
      Signed-off-by: 's avatarH. Peter Anvin <hpa@linux.intel.com>
      ac2cbab2
  24. 30 Oct, 2012 7 commits
  25. 21 Aug, 2012 1 commit
  26. 29 May, 2012 1 commit
  27. 20 Mar, 2012 1 commit
  28. 07 Mar, 2012 1 commit
  29. 06 Dec, 2011 1 commit
  30. 06 Jun, 2011 1 commit
    • FUJITA Tomonori's avatar
      swiotlb: Export swioltb_nr_tbl and utilize it as appropiate. · 5f98ecdb
      FUJITA Tomonori authored
      By default the io_tlb_nslabs is set to zero, and gets set to
      whatever value is passed in via swiotlb_init_with_tbl function.
      The default value passed in is 64MB. However, if the user provides
      the 'swiotlb=<nslabs>' the default value is ignored and
      the value provided by the user is used... Except when the SWIOTLB
      is used under Xen - there the default value of 64MB is used and
      the Xen-SWIOTLB has no mechanism to get the 'io_tlb_nslabs' filled
      out by setup_io_tlb_npages functions. This patch provides a function
      for the Xen-SWIOTLB to call to see if the io_tlb_nslabs is set
      and if so use that value.
      Signed-off-by: 's avatarFUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp>
      Signed-off-by: 's avatarKonrad Rzeszutek Wilk <konrad.wilk@oracle.com>
      5f98ecdb