1. 15 Feb, 2021 2 commits
  2. 12 Feb, 2021 7 commits
  3. 11 Feb, 2021 12 commits
  4. 10 Feb, 2021 11 commits
  5. 09 Feb, 2021 8 commits
    • Paolo Bonzini's avatar
      Documentation: kvm: fix warning · 9294b8a1
      Paolo Bonzini authored
      Documentation/virt/kvm/api.rst:4927: WARNING: Title underline too short.
      
      4.130 KVM_XEN_VCPU_GET_ATTR
      --------------------------
      
      Fixes: e1f68169 ("KVM: Add documentation for Xen hypercall and shared_info updates")
      Reported-by: default avatarStephen Rothwell <sfr@canb.auug.org.au>
      Signed-off-by: default avatarPaolo Bonzini <pbonzini@redhat.com>
      9294b8a1
    • David Woodhouse's avatar
      KVM: x86/xen: Allow reset of Xen attributes · 0c165b3c
      David Woodhouse authored
      In order to support Xen SHUTDOWN_soft_reset (for guest kexec, etc.) the
      VMM needs to be able to tear everything down and return the Xen features
      to a clean slate.
      Signed-off-by: default avatarDavid Woodhouse <dwmw@amazon.co.uk>
      Message-Id: <20210208232326.1830370-1-dwmw2@infradead.org>
      Signed-off-by: default avatarPaolo Bonzini <pbonzini@redhat.com>
      0c165b3c
    • Maciej S. Szmigiero's avatar
      KVM: x86/mmu: Make HVA handler retpoline-friendly · 8f5c44f9
      Maciej S. Szmigiero authored
      When retpolines are enabled they have high overhead in the inner loop
      inside kvm_handle_hva_range() that iterates over the provided memory area.
      
      Let's mark this function and its TDP MMU equivalent __always_inline so
      compiler will be able to change the call to the actual handler function
      inside each of them into a direct one.
      
      This significantly improves performance on the unmap test on the existing
      kernel memslot code (tested on a Xeon 8167M machine):
      30 slots in use:
      Test       Before   After     Improvement
      Unmap      0.0353s  0.0334s   5%
      Unmap 2M   0.00104s 0.000407s 61%
      
      509 slots in use:
      Test       Before   After     Improvement
      Unmap      0.0742s  0.0740s   None
      Unmap 2M   0.00221s 0.00159s  28%
      
      Looks like having an indirect call in these functions (and, so, a
      retpoline) might have interfered with unrolling of the whole loop in the
      CPU.
      Signed-off-by: default avatarMaciej S. Szmigiero <maciej.szmigiero@oracle.com>
      Message-Id: <732d3fe9eb68aa08402a638ab0309199fa89ae56.1612810129.git.maciej.szmigiero@oracle.com>
      Signed-off-by: default avatarPaolo Bonzini <pbonzini@redhat.com>
      8f5c44f9
    • Vitaly Kuznetsov's avatar
      KVM: x86: hyper-v: Drop hv_vcpu_to_vcpu() helper · b9ce0f86
      Vitaly Kuznetsov authored
      hv_vcpu_to_vcpu() helper is only used by other helpers and
      is not very complex, we can drop it without much regret.
      Signed-off-by: default avatarVitaly Kuznetsov <vkuznets@redhat.com>
      Message-Id: <20210126134816.1880136-16-vkuznets@redhat.com>
      Signed-off-by: default avatarPaolo Bonzini <pbonzini@redhat.com>
      b9ce0f86
    • Vitaly Kuznetsov's avatar
      KVM: x86: hyper-v: Allocate Hyper-V context lazily · fc08b628
      Vitaly Kuznetsov authored
      Hyper-V context is only needed for guests which use Hyper-V emulation in
      KVM (e.g. Windows/Hyper-V guests) so we don't actually need to allocate
      it in kvm_arch_vcpu_create(), we can postpone the action until Hyper-V
      specific MSRs are accessed or SynIC is enabled.
      
      Once allocated, let's keep the context alive for the lifetime of the vCPU
      as an attempt to free it would require additional synchronization with
      other vCPUs and normally it is not supposed to happen.
      
      Note, Hyper-V style hypercall enablement is done by writing to
      HV_X64_MSR_GUEST_OS_ID so we don't need to worry about allocating Hyper-V
      context from kvm_hv_hypercall().
      Signed-off-by: default avatarVitaly Kuznetsov <vkuznets@redhat.com>
      Message-Id: <20210126134816.1880136-15-vkuznets@redhat.com>
      Signed-off-by: default avatarPaolo Bonzini <pbonzini@redhat.com>
      fc08b628
    • Vitaly Kuznetsov's avatar
      KVM: x86: hyper-v: Make Hyper-V emulation enablement conditional · 8f014550
      Vitaly Kuznetsov authored
      Hyper-V emulation is enabled in KVM unconditionally. This is bad at least
      from security standpoint as it is an extra attack surface. Ideally, there
      should be a per-VM capability explicitly enabled by VMM but currently it
      is not the case and we can't mandate one without breaking backwards
      compatibility. We can, however, check guest visible CPUIDs and only enable
      Hyper-V emulation when "Hv#1" interface was exposed in
      HYPERV_CPUID_INTERFACE.
      
      Note, VMMs are free to act in any sequence they like, e.g. they can try
      to set MSRs first and CPUIDs later so we still need to allow the host
      to read/write Hyper-V specific MSRs unconditionally.
      Signed-off-by: default avatarVitaly Kuznetsov <vkuznets@redhat.com>
      Message-Id: <20210126134816.1880136-14-vkuznets@redhat.com>
      [Add selftest vcpu_set_hv_cpuid API to avoid breaking xen_vmcall_test. - Paolo]
      Signed-off-by: default avatarPaolo Bonzini <pbonzini@redhat.com>
      8f014550
    • Vitaly Kuznetsov's avatar
      KVM: x86: hyper-v: Allocate 'struct kvm_vcpu_hv' dynamically · 4592b7ea
      Vitaly Kuznetsov authored
      Hyper-V context is only needed for guests which use Hyper-V emulation in
      KVM (e.g. Windows/Hyper-V guests). 'struct kvm_vcpu_hv' is, however, quite
      big, it accounts for more than 1/4 of the total 'struct kvm_vcpu_arch'
      which is also quite big already. This all looks like a waste.
      
      Allocate 'struct kvm_vcpu_hv' dynamically. This patch does not bring any
      (intentional) functional change as we still allocate the context
      unconditionally but it paves the way to doing that only when needed.
      Signed-off-by: default avatarVitaly Kuznetsov <vkuznets@redhat.com>
      Message-Id: <20210126134816.1880136-13-vkuznets@redhat.com>
      Signed-off-by: default avatarPaolo Bonzini <pbonzini@redhat.com>
      4592b7ea
    • Vitaly Kuznetsov's avatar
      KVM: x86: hyper-v: Prepare to meet unallocated Hyper-V context · f2bc14b6
      Vitaly Kuznetsov authored
      Currently, Hyper-V context is part of 'struct kvm_vcpu_arch' and is always
      available. As a preparation to allocating it dynamically, check that it is
      not NULL at call sites which can normally proceed without it i.e. the
      behavior is identical to the situation when Hyper-V emulation is not being
      used by the guest.
      
      When Hyper-V context for a particular vCPU is not allocated, we may still
      need to get 'vp_index' from there. E.g. in a hypothetical situation when
      Hyper-V emulation was enabled on one CPU and wasn't on another, Hyper-V
      style send-IPI hypercall may still be used. Luckily, vp_index is always
      initialized to kvm_vcpu_get_idx() and can only be changed when Hyper-V
      context is present. Introduce kvm_hv_get_vpindex() helper for
      simplification.
      
      No functional change intended.
      Signed-off-by: default avatarVitaly Kuznetsov <vkuznets@redhat.com>
      Message-Id: <20210126134816.1880136-12-vkuznets@redhat.com>
      Signed-off-by: default avatarPaolo Bonzini <pbonzini@redhat.com>
      f2bc14b6