1. 29 Jan, 2018 2 commits
  2. 08 Dec, 2017 1 commit
  3. 10 Nov, 2017 1 commit
    • Michael S. Tsirkin's avatar
      locking/x86: Use LOCK ADD for smp_mb() instead of MFENCE · 450cbdd0
      Michael S. Tsirkin authored
      MFENCE appears to be way slower than a locked instruction - let's use
      LOCK ADD unconditionally, as we always did on old 32-bit.
      
      Performance testing results:
      
        perf stat -r 10 -- ./virtio_ring_0_9 --sleep --host-affinity 0 --guest-affinity 0
        Before:
               0.922565990 seconds time elapsed                                          ( +-  1.15% )
        After:
               0.578667024 seconds time elapsed                                          ( +-  1.21% )
      
      i.e. about ~60% faster.
      
      Just poking at SP would be the most natural, but if we then read the
      value from SP, we get a false dependency which will slow us down.
      
      This was noted in this article:
      
        http://shipilev.net/blog/2014/on-the-fence-with-dependencies/
      
      
      
      And is easy to reproduce by sticking a barrier in a small non-inline
      function.
      
      So let's use a negative offset - which avoids this problem since we
      build with the red zone disabled.
      
      For userspace, use an address just below the redzone.
      
      The one difference between LOCK ADD and MFENCE is that LOCK ADD does
      not affect CLFLUSH, previous patches converted all uses of CLFLUSH to
      call mb(), such that changes to smp_mb() won't affect it.
      
      Update mb/rmb/wmb() on 32-bit to use the negative offset, too, for
      consistency.
      
      As a follow-up, it might be worth considering switching users
      of CLFLUSH to another API (e.g. clflush_mb()?) - we will
      then be able to convert mb() to smp_mb() again.
      
      Also arguably, GCC should switch to use LOCK ADD for __sync_synchronize().
      This might be worth pursuing separately.
      Suggested-by: default avatarAndy Lutomirski <luto@amacapital.net>
      Signed-off-by: default avatarMichael S. Tsirkin <mst@redhat.com>
      Acked-by: default avatarPeter Zijlstra <peterz@infradead.org>
      Acked-by: default avatarThomas Gleixner <tglx@linutronix.de>
      Cc: Andrew Morton <akpm@linux-foundation.org>
      Cc: Andy Lutomirski <luto@kernel.org>
      Cc: Borislav Petkov <bp@alien8.de>
      Cc: Brian Gerst <brgerst@gmail.com>
      Cc: Denys Vlasenko <dvlasenk@redhat.com>
      Cc: H. Peter Anvin <hpa@zytor.com>
      Cc: Josh Poimboeuf <jpoimboe@redhat.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
      Cc: qemu-devel@nongnu.org
      Cc: virtualization@lists.linux-foundation.org
      Link: http://lkml.kernel.org/r/1509118355-4890-1-git-send-email-mst@redhat.com
      
      Signed-off-by: default avatarIngo Molnar <mingo@kernel.org>
      450cbdd0
  4. 02 Nov, 2017 1 commit
    • Greg Kroah-Hartman's avatar
      License cleanup: add SPDX GPL-2.0 license identifier to files with no license · b2441318
      Greg Kroah-Hartman authored
      Many source files in the tree are missing licensing information, which
      makes it harder for compliance tools to determine the correct license.
      
      By default all files without license information are under the default
      license of the kernel, which is GPL version 2.
      
      Update the files which contain no license information with the 'GPL-2.0'
      SPDX license identifier.  The SPDX identifier is a legally binding
      shorthand, which can be used instead of the full boiler plate text.
      
      This patch is based on work done by Thomas Gleixner and Kate Stewart and
      Philippe Ombredanne.
      
      How this work was done:
      
      Patches were generated and checked against linux-4.14-rc6 for a subset of
      the use cases:
       - file had no licensing information it it.
       - file was a */uapi/* one with no licensing information in it,
       - file was a */uapi/* one with existing licensing information,
      
      Further patches will be generated in subsequent months to fix up cases
      where non-standard...
      b2441318
  5. 09 May, 2017 3 commits
  6. 02 May, 2017 2 commits
  7. 19 Jan, 2017 2 commits
  8. 15 Dec, 2016 2 commits
  9. 30 Oct, 2016 3 commits
  10. 15 Aug, 2016 2 commits
  11. 01 Jul, 2016 1 commit
  12. 15 Jun, 2016 1 commit
  13. 06 Jun, 2016 3 commits
  14. 22 May, 2016 2 commits
  15. 02 Mar, 2016 1 commit
    • Andy Lutomirski's avatar
      virtio_ring: Support DMA APIs · 780bc790
      Andy Lutomirski authored
      
      
      virtio_ring currently sends the device (usually a hypervisor)
      physical addresses of its I/O buffers.  This is okay when DMA
      addresses and physical addresses are the same thing, but this isn't
      always the case.  For example, this never works on Xen guests, and
      it is likely to fail if a physical "virtio" device ever ends up
      behind an IOMMU or swiotlb.
      
      The immediate use case for me is to enable virtio on Xen guests.
      For that to work, we need vring to support DMA address translation
      as well as a corresponding change to virtio_pci or to another
      driver.
      Signed-off-by: default avatarAndy Lutomirski <luto@kernel.org>
      Signed-off-by: default avatarMichael S. Tsirkin <mst@redhat.com>
      780bc790
  16. 26 Jan, 2016 2 commits
  17. 07 Dec, 2015 2 commits
  18. 16 Sep, 2015 1 commit
  19. 09 Sep, 2015 1 commit
  20. 15 Dec, 2014 6 commits
  21. 09 Dec, 2014 1 commit