lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite for Android: free password hash cracker in your pocket
[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Date:   Wed,  7 Jun 2017 13:00:51 +0200
From:   Vitaly Kuznetsov <vkuznets@...hat.com>
To:     devel@...uxdriverproject.org
Cc:     x86@...nel.org, linux-kernel@...r.kernel.org,
        "K. Y. Srinivasan" <kys@...rosoft.com>,
        Haiyang Zhang <haiyangz@...rosoft.com>,
        Stephen Hemminger <sthemmin@...rosoft.com>,
        Thomas Gleixner <tglx@...utronix.de>,
        Ingo Molnar <mingo@...hat.com>,
        "H. Peter Anvin" <hpa@...or.com>,
        Steven Rostedt <rostedt@...dmis.org>,
        Jork Loeser <Jork.Loeser@...rosoft.com>,
        Simon Xiao <sixiao@...rosoft.com>,
        Andy Lutomirski <luto@...nel.org>,
        Andy Shevchenko <andy.shevchenko@...il.com>
Subject: [PATCH v7 00/10] Hyper-V: paravirtualized remote TLB flushing and hypercall improvements

Changes since v6:
- Fix a bug in cpumask_to_vp_set() by setting valid_bank_mask right,
  add a check for > 64 banks and fall back to HV_FLUSH_ALL_PROCESSORS
  [Jork Loeser]
- Drop DEFINE_TRACE() from mmu.c, change tracing magic a bit to
  keep things compiling (steal the idea from x86/include/asm/trace/mpx.h)
  [Steven Rostedt]

Original description:

Hyper-V supports hypercalls for doing local and remote TLB flushing and
gives its guests hints when using hypercall is preferred. While doing
hypercalls for local TLB flushes is probably not practical (and is not
being suggested by modern Hyper-V versions) remote TLB flush with a
hypercall brings significant improvement.

To test the series I wrote a special 'TLB trasher': on a 16 vCPU guest I
was creating 32 threads which were doing 100000 mmap/munmaps each on some
big file. Here are the results:

Before:
# time ./pthread_mmap ./randfile 
real	3m33.118s
user	0m3.698s
sys	3m16.624s

After:
# time ./pthread_mmap ./randfile 
real	2m19.920s
user	0m2.662s
sys	2m9.948s

This series brings a number of small improvements along the way: fast
hypercall implementation and using it for event signaling, rep hypercalls
implementation, hyperv tracing subsystem (which only traces the newly added
remote TLB flush for now).

Vitaly Kuznetsov (10):
  x86/hyper-v: include hyperv/ only when CONFIG_HYPERV is set
  x86/hyper-v: stash the max number of virtual/logical processor
  x86/hyper-v: make hv_do_hypercall() inline
  x86/hyper-v: fast hypercall implementation
  hyper-v: use fast hypercall for HVCALL_SIGNAL_EVENT
  x86/hyper-v: implement rep hypercalls
  hyper-v: globalize vp_index
  x86/hyper-v: use hypercall for remote TLB flush
  x86/hyper-v: support extended CPU ranges for TLB flush hypercalls
  tracing/hyper-v: trace hyperv_mmu_flush_tlb_others()

 MAINTAINERS                         |   1 +
 arch/x86/Kbuild                     |   2 +-
 arch/x86/hyperv/Makefile            |   2 +-
 arch/x86/hyperv/hv_init.c           |  90 ++++++------
 arch/x86/hyperv/mmu.c               | 267 ++++++++++++++++++++++++++++++++++++
 arch/x86/include/asm/mshyperv.h     | 148 +++++++++++++++++++-
 arch/x86/include/asm/trace/hyperv.h |  38 +++++
 arch/x86/include/uapi/asm/hyperv.h  |  17 +++
 arch/x86/kernel/cpu/mshyperv.c      |  13 +-
 drivers/hv/channel_mgmt.c           |  20 +--
 drivers/hv/connection.c             |   7 +-
 drivers/hv/hv.c                     |   9 --
 drivers/hv/hyperv_vmbus.h           |  11 --
 drivers/hv/vmbus_drv.c              |  17 ---
 drivers/pci/host/pci-hyperv.c       |  10 +-
 include/linux/hyperv.h              |  17 +--
 16 files changed, 538 insertions(+), 131 deletions(-)
 create mode 100644 arch/x86/hyperv/mmu.c
 create mode 100644 arch/x86/include/asm/trace/hyperv.h

-- 
2.9.4

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ