1. 28 2月, 2019 1 次提交
  2. 21 12月, 2018 1 次提交
  3. 15 12月, 2018 5 次提交
  4. 09 10月, 2018 1 次提交
  5. 20 9月, 2018 1 次提交
  6. 06 8月, 2018 1 次提交
  7. 08 7月, 2018 1 次提交
  8. 03 7月, 2018 1 次提交
    • M
      Drivers: hv: vmbus: Make TLFS #define names architecture neutral · 7dc9b6b8
      Michael Kelley 提交于
      The Hyper-V feature and hint flags in hyperv-tlfs.h are all defined
      with the string "X64" in the name.  Some of these flags are indeed
      x86/x64 specific, but others are not.  For the ones that are used
      in architecture independent Hyper-V driver code, or will be used in
      the upcoming support for Hyper-V for ARM64, this patch removes the
      "X64" from the name.
      
      This patch changes the flags that are currently known to be
      used on multiple architectures. Hyper-V for ARM64 is still a
      work-in-progress and the Top Level Functional Spec (TLFS) has not
      been separated into x86/x64 and ARM64 areas.  So additional flags
      may need to be updated later.
      
      This patch only changes symbol names.  There are no functional
      changes.
      Signed-off-by: NMichael Kelley <mikelley@microsoft.com>
      Signed-off-by: NK. Y. Srinivasan <kys@microsoft.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      7dc9b6b8
  9. 26 5月, 2018 1 次提交
  10. 19 5月, 2018 2 次提交
  11. 15 5月, 2018 1 次提交
    • V
      KVM: x86: VMX: hyper-v: Enlightened MSR-Bitmap support · ceef7d10
      Vitaly Kuznetsov 提交于
      Enlightened MSR-Bitmap is a natural extension of Enlightened VMCS:
      Hyper-V Top Level Functional Specification states:
      
      "The L1 hypervisor may collaborate with the L0 hypervisor to make MSR
      accesses more efficient. It can enable enlightened MSR bitmaps by setting
      the corresponding field in the enlightened VMCS to 1. When enabled, the L0
      hypervisor does not monitor the MSR bitmaps for changes. Instead, the L1
      hypervisor must invalidate the corresponding clean field after making
      changes to one of the MSR bitmaps."
      
      I reached out to Hyper-V team for additional details and I got the
      following information:
      
      "Current Hyper-V implementation works as following:
      
      If the enlightened MSR bitmap is not enabled:
      - All MSR accesses of L2 guests cause physical VM-Exits
      
      If the enlightened MSR bitmap is enabled:
      - Physical VM-Exits for L2 accesses to certain MSRs (currently FS_BASE,
        GS_BASE and KERNEL_GS_BASE) are avoided, thus making these MSR accesses
        faster."
      
      I tested my series with a tight rdmsrl loop in L2, for KERNEL_GS_BASE the
      results are:
      
      Without Enlightened MSR-Bitmap: 1300 cycles/read
      With Enlightened MSR-Bitmap: 120 cycles/read
      Signed-off-by: NVitaly Kuznetsov <vkuznets@redhat.com>
      Tested-by: NLan Tianyu <Tianyu.Lan@microsoft.com>
      Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
      ceef7d10
  12. 29 3月, 2018 6 次提交
  13. 17 3月, 2018 1 次提交
  14. 07 3月, 2018 2 次提交
    • M
      Drivers: hv: vmbus: Implement Direct Mode for stimer0 · 248e742a
      Michael Kelley 提交于
      The 2016 version of Hyper-V offers the option to operate the guest VM
      per-vcpu stimer's in Direct Mode, which means the timer interupts on its
      own vector rather than queueing a VMbus message. Direct Mode reduces
      timer processing overhead in both the hypervisor and the guest, and
      avoids having timer interrupts pollute the VMbus interrupt stream for
      the synthetic NIC and storage.  This patch enables Direct Mode by
      default on stimer0 when running on a version of Hyper-V that supports
      it.
      
      In prep for coming support of Hyper-V on ARM64, the arch independent
      portion of the code contains calls to routines that will be populated
      on ARM64 but are not needed and do nothing on x86.
      Signed-off-by: NMichael Kelley <mikelley@microsoft.com>
      Signed-off-by: NK. Y. Srinivasan <kys@microsoft.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      248e742a
    • R
      kvm: x86: hyperv: guest->host event signaling via eventfd · faeb7833
      Roman Kagan 提交于
      In Hyper-V, the fast guest->host notification mechanism is the
      SIGNAL_EVENT hypercall, with a single parameter of the connection ID to
      signal.
      
      Currently this hypercall incurs a user exit and requires the userspace
      to decode the parameters and trigger the notification of the potentially
      different I/O context.
      
      To avoid the costly user exit, process this hypercall and signal the
      corresponding eventfd in KVM, similar to ioeventfd.  The association
      between the connection id and the eventfd is established via the newly
      introduced KVM_HYPERV_EVENTFD ioctl, and maintained in an
      (srcu-protected) IDR.
      Signed-off-by: NRoman Kagan <rkagan@virtuozzo.com>
      Reviewed-by: NDavid Hildenbrand <david@redhat.com>
      [asm/hyperv.h changes approved by KY Srinivasan. - Radim]
      Signed-off-by: NRadim Krčmář <rkrcmar@redhat.com>
      faeb7833
  15. 20 2月, 2018 1 次提交
  16. 31 1月, 2018 1 次提交
    • V
      x86/hyperv: Reenlightenment notifications support · 93286261
      Vitaly Kuznetsov 提交于
      Hyper-V supports Live Migration notification. This is supposed to be used
      in conjunction with TSC emulation: when a VM is migrated to a host with
      different TSC frequency for some short period the host emulates the
      accesses to TSC and sends an interrupt to notify about the event. When the
      guest is done updating everything it can disable TSC emulation and
      everything will start working fast again.
      
      These notifications weren't required until now as Hyper-V guests are not
      supposed to use TSC as a clocksource: in Linux the TSC is even marked as
      unstable on boot. Guests normally use 'tsc page' clocksource and host
      updates its values on migrations automatically.
      
      Things change when with nested virtualization: even when the PV
      clocksources (kvm-clock or tsc page) are passed through to the nested
      guests the TSC frequency and frequency changes need to be know..
      
      Hyper-V Top Level Functional Specification (as of v5.0b) wrongly specifies
      EAX:BIT(12) of CPUID:0x40000009 as the feature identification bit. The
      right one to check is EAX:BIT(13) of CPUID:0x40000003. I was assured that
      the fix in on the way.
      Signed-off-by: NVitaly Kuznetsov <vkuznets@redhat.com>
      Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
      Reviewed-by: NThomas Gleixner <tglx@linutronix.de>
      Cc: Stephen Hemminger <sthemmin@microsoft.com>
      Cc: kvm@vger.kernel.org
      Cc: Radim Krčmář <rkrcmar@redhat.com>
      Cc: Haiyang Zhang <haiyangz@microsoft.com>
      Cc: "Michael Kelley (EOSG)" <Michael.H.Kelley@microsoft.com>
      Cc: Roman Kagan <rkagan@virtuozzo.com>
      Cc: Andy Lutomirski <luto@kernel.org>
      Cc: devel@linuxdriverproject.org
      Cc: Paolo Bonzini <pbonzini@redhat.com>
      Cc: "K. Y. Srinivasan" <kys@microsoft.com>
      Cc: Cathy Avery <cavery@redhat.com>
      Cc: Mohammed Gamal <mmorsy@redhat.com>
      Link: https://lkml.kernel.org/r/20180124132337.30138-4-vkuznets@redhat.com
      93286261
  17. 02 11月, 2017 1 次提交
    • G
      License cleanup: add SPDX license identifier to uapi header files with no license · 6f52b16c
      Greg Kroah-Hartman 提交于
      Many user space API headers are missing licensing information, which
      makes it hard for compliance tools to determine the correct license.
      
      By default are files without license information under the default
      license of the kernel, which is GPLV2.  Marking them GPLV2 would exclude
      them from being included in non GPLV2 code, which is obviously not
      intended. The user space API headers fall under the syscall exception
      which is in the kernels COPYING file:
      
         NOTE! This copyright does *not* cover user programs that use kernel
         services by normal system calls - this is merely considered normal use
         of the kernel, and does *not* fall under the heading of "derived work".
      
      otherwise syscall usage would not be possible.
      
      Update the files which contain no license information with an SPDX
      license identifier.  The chosen identifier is 'GPL-2.0 WITH
      Linux-syscall-note' which is the officially assigned identifier for the
      Linux syscall exception.  SPDX license identifiers are 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.  See the previous patch in this series for the
      methodology of how this patch was researched.
      Reviewed-by: NKate Stewart <kstewart@linuxfoundation.org>
      Reviewed-by: NPhilippe Ombredanne <pombredanne@nexb.com>
      Reviewed-by: NThomas Gleixner <tglx@linutronix.de>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      6f52b16c
  18. 13 9月, 2017 1 次提交
  19. 31 8月, 2017 1 次提交
  20. 11 8月, 2017 1 次提交
    • V
      x86/hyper-v: Use hypercall for remote TLB flush · 2ffd9e33
      Vitaly Kuznetsov 提交于
      Hyper-V host can suggest us to use hypercall for doing remote TLB flush,
      this is supposed to work faster than IPIs.
      
      Implementation details: to do HvFlushVirtualAddress{Space,List} hypercalls
      we need to put the input somewhere in memory and we don't really want to
      have memory allocation on each call so we pre-allocate per cpu memory areas
      on boot.
      
      pv_ops patching is happening very early so we need to separate
      hyperv_setup_mmu_ops() and hyper_alloc_mmu().
      
      It is possible and easy to implement local TLB flushing too and there is
      even a hint for that. However, I don't see a room for optimization on the
      host side as both hypercall and native tlb flush will result in vmexit. The
      hint is also not set on modern Hyper-V versions.
      Signed-off-by: NVitaly Kuznetsov <vkuznets@redhat.com>
      Reviewed-by: NAndy Shevchenko <andy.shevchenko@gmail.com>
      Reviewed-by: NStephen Hemminger <sthemmin@microsoft.com>
      Cc: Andy Lutomirski <luto@kernel.org>
      Cc: Haiyang Zhang <haiyangz@microsoft.com>
      Cc: Jork Loeser <Jork.Loeser@microsoft.com>
      Cc: K. Y. Srinivasan <kys@microsoft.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Simon Xiao <sixiao@microsoft.com>
      Cc: Steven Rostedt <rostedt@goodmis.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: devel@linuxdriverproject.org
      Link: http://lkml.kernel.org/r/20170802160921.21791-8-vkuznets@redhat.comSigned-off-by: NIngo Molnar <mingo@kernel.org>
      2ffd9e33
  21. 03 7月, 2017 1 次提交
  22. 22 6月, 2017 1 次提交
  23. 17 3月, 2017 2 次提交
  24. 20 1月, 2017 1 次提交
  25. 17 2月, 2016 2 次提交
  26. 17 12月, 2015 2 次提交
    • A
      kvm/x86: Hyper-V SynIC timers · 1f4b34f8
      Andrey Smetanin 提交于
      Per Hyper-V specification (and as required by Hyper-V-aware guests),
      SynIC provides 4 per-vCPU timers.  Each timer is programmed via a pair
      of MSRs, and signals expiration by delivering a special format message
      to the configured SynIC message slot and triggering the corresponding
      synthetic interrupt.
      
      Note: as implemented by this patch, all periodic timers are "lazy"
      (i.e. if the vCPU wasn't scheduled for more than the timer period the
      timer events are lost), regardless of the corresponding configuration
      MSR.  If deemed necessary, the "catch up" mode (the timer period is
      shortened until the timer catches up) will be implemented later.
      
      Changes v2:
      * Use remainder to calculate periodic timer expiration time
      Signed-off-by: NAndrey Smetanin <asmetanin@virtuozzo.com>
      Reviewed-by: NRoman Kagan <rkagan@virtuozzo.com>
      CC: Gleb Natapov <gleb@kernel.org>
      CC: Paolo Bonzini <pbonzini@redhat.com>
      CC: "K. Y. Srinivasan" <kys@microsoft.com>
      CC: Haiyang Zhang <haiyangz@microsoft.com>
      CC: Vitaly Kuznetsov <vkuznets@redhat.com>
      CC: Roman Kagan <rkagan@virtuozzo.com>
      CC: Denis V. Lunev <den@openvz.org>
      CC: qemu-devel@nongnu.org
      Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
      1f4b34f8
    • A
      drivers/hv: Move struct hv_timer_message_payload into UAPI Hyper-V x86 header · c71acc4c
      Andrey Smetanin 提交于
      This struct is required for Hyper-V SynIC timers implementation inside KVM
      and for upcoming Hyper-V VMBus support by userspace(QEMU). So place it into
      Hyper-V UAPI header.
      Signed-off-by: NAndrey Smetanin <asmetanin@virtuozzo.com>
      CC: Gleb Natapov <gleb@kernel.org>
      CC: Paolo Bonzini <pbonzini@redhat.com>
      CC: "K. Y. Srinivasan" <kys@microsoft.com>
      CC: Haiyang Zhang <haiyangz@microsoft.com>
      CC: Vitaly Kuznetsov <vkuznets@redhat.com>
      CC: Roman Kagan <rkagan@virtuozzo.com>
      CC: Denis V. Lunev <den@openvz.org>
      CC: qemu-devel@nongnu.org
      Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
      c71acc4c