1. 09 Nov, 2020 1 commit
  2. 21 Oct, 2020 5 commits
    • Sean Christopherson's avatar
      KVM: x86: Move call to update_exception_bitmap() into VMX code · a6337a35
      Sean Christopherson authored
      
      Now that vcpu_after_set_cpuid() and update_exception_bitmap() are called
      back-to-back, subsume the exception bitmap update into the common CPUID
      update.  Drop the SVM invocation entirely as SVM's exception bitmap
      doesn't vary with respect to guest CPUID.
      Signed-off-by: default avatarSean Christopherson <sean.j.christopherson@intel.com>
      Message-Id: <20200930041659.28181-4-sean.j.christopherson@intel.com>
      Signed-off-by: default avatarPaolo Bonzini <pbonzini@redhat.com>
      a6337a35
    • Sean Christopherson's avatar
      KVM: x86: Invoke vendor's vcpu_after_set_cpuid() after all common updates · c44d9b34
      Sean Christopherson authored
      Move the call to kvm_x86_ops.vcpu_after_set_cpuid() to the very end of
      kvm_vcpu_after_set_cpuid() to allow the vendor implementation to react
      to changes made by the common code.  In the near future, this will be
      used by VMX to update its CR4 guest/host masks to account for reserved
      bits.  In the long term, SGX support will update the allowed XCR0 mask
      for enclaves based on the vCPU's allowed XCR0.
      
      vcpu_after_set_cpuid() (nee kvm_update_cpuid()) was originally added by
      commit 2acf923e
      
       ("KVM: VMX: Enable XSAVE/XRSTOR for guest"), and was
      called separately after kvm_x86_ops.vcpu_after_set_cpuid() (nee
      kvm_x86_ops->cpuid_update()).  There is no indication that the placement
      of the common code updates after the vendor updates was anything more
      than a "new function at the end" decision.
      
      Inspection of the current code reveals no dependency on kvm_x86_ops'
      vcpu_after_set_cpuid() in kvm_vcpu_after_set_cpuid() or any of its
      helpers.  The bulk of the common code depends only on the guest's CPUID
      configuration, kvm_mmu_reset_context() does not consume dynamic vendor
      state, and there are no collisions between kvm_pmu_refresh() and VMX's
      update of PT state.
      Signed-off-by: default avatarSean Christopherson <sean.j.christopherson@intel.com>
      Message-Id: <20200930041659.28181-3-sean.j.christopherson@intel.com>
      Signed-off-by: default avatarPaolo Bonzini <pbonzini@redhat.com>
      c44d9b34
    • Vitaly Kuznetsov's avatar
      KVM: x86: allocate vcpu->arch.cpuid_entries dynamically · 255cbecf
      Vitaly Kuznetsov authored
      
      The current limit for guest CPUID leaves (KVM_MAX_CPUID_ENTRIES, 80)
      is reported to be insufficient but before we bump it let's switch to
      allocating vcpu->arch.cpuid_entries[] array dynamically. Currently,
      'struct kvm_cpuid_entry2' is 40 bytes so vcpu->arch.cpuid_entries is
      3200 bytes which accounts for 1/4 of the whole 'struct kvm_vcpu_arch'
      but having it pre-allocated (for all vCPUs which we also pre-allocate)
      gives us no real benefits.
      
      Another plus of the dynamic allocation is that we now do kvm_check_cpuid()
      check before we assign anything to vcpu->arch.cpuid_nent/cpuid_entries so
      no changes are made in case the check fails.
      
      Opportunistically remove unneeded 'out' labels from
      kvm_vcpu_ioctl_set_cpuid()/kvm_vcpu_ioctl_set_cpuid2() and return
      directly whenever possible.
      Signed-off-by: default avatarVitaly Kuznetsov <vkuznets@redhat.com>
      Message-Id: <20201001130541.1398392-3-vkuznets@redhat.com>
      Signed-off-by: default avatarPaolo Bonzini <pbonzini@redhat.com>
      Reviewed-by: default avatarMaxim Levitsky <mlevitsk@redhat.com>
      255cbecf
    • Vitaly Kuznetsov's avatar
      KVM: x86: disconnect kvm_check_cpuid() from vcpu->arch.cpuid_entries · f69858fc
      Vitaly Kuznetsov authored
      
      As a preparatory step to allocating vcpu->arch.cpuid_entries dynamically
      make kvm_check_cpuid() check work with an arbitrary 'struct kvm_cpuid_entry2'
      array.
      
      Currently, when kvm_check_cpuid() fails we reset vcpu->arch.cpuid_nent to
      0 and this is kind of weird, i.e. one would expect CPUIDs to remain
      unchanged when KVM_SET_CPUID[2] call fails.
      
      No functional change intended. It would've been possible to move the updated
      kvm_check_cpuid() in kvm_vcpu_ioctl_set_cpuid2() and check the supplied
      input before we start updating vcpu->arch.cpuid_entries/nent but we
      can't do the same in kvm_vcpu_ioctl_set_cpuid() as we'll have to copy
      'struct kvm_cpuid_entry' entries first. The change will be made when
      vcpu->arch.cpuid_entries[] array becomes allocated dynamically.
      Suggested-by: default avatarSean Christopherson <sean.j.christopherson@intel.com>
      Signed-off-by: default avatarVitaly Kuznetsov <vkuznets@redhat.com>
      Message-Id: <20201001130541.1398392-2-vkuznets@redhat.com>
      Signed-off-by: default avatarPaolo Bonzini <pbonzini@redhat.com>
      f69858fc
    • Oliver Upton's avatar
      kvm: x86: only provide PV features if enabled in guest's CPUID · 66570e96
      Oliver Upton authored
      
      KVM unconditionally provides PV features to the guest, regardless of the
      configured CPUID. An unwitting guest that doesn't check
      KVM_CPUID_FEATURES before use could access paravirt features that
      userspace did not intend to provide. Fix this by checking the guest's
      CPUID before performing any paravirtual operations.
      
      Introduce a capability, KVM_CAP_ENFORCE_PV_FEATURE_CPUID, to gate the
      aforementioned enforcement. Migrating a VM from a host w/o this patch to
      a host with this patch could silently change the ABI exposed to the
      guest, warranting that we default to the old behavior and opt-in for
      the new one.
      Reviewed-by: default avatarJim Mattson <jmattson@google.com>
      Reviewed-by: default avatarPeter Shier <pshier@google.com>
      Signed-off-by: default avatarOliver Upton <oupton@google.com>
      Change-Id: I202a0926f65035b872bfe8ad15307c026de59a98
      Message-Id: <20200818152429.1923996-4-oupton@google.com>
      Reviewed-by: default avatarWanpeng Li <wanpengli@tencent.com>
      Signed-off-by: default avatarPaolo Bonzini <pbonzini@redhat.com>
      66570e96
  3. 28 Sep, 2020 1 commit
  4. 30 Aug, 2020 1 commit
  5. 09 Aug, 2020 1 commit
    • Paolo Bonzini's avatar
      x86: Expose SERIALIZE for supported cpuid · 43bd9ef4
      Paolo Bonzini authored
      
      The SERIALIZE instruction is supported by Tntel processors, like
      Sapphire Rapids.  SERIALIZE is a faster serializing instruction which
      does not modify registers, arithmetic flags or memory, will not cause VM
      exit. It's availability is indicated by CPUID.(EAX=7,ECX=0):ECX[bit 14].
      
      Expose it in KVM supported CPUID.  This way, KVM could pass this
      information to guests and they can make use of these features accordingly.
      Signed-off-by: default avatarCathy Zhang <cathy.zhang@intel.com>
      Signed-off-by: default avatarPaolo Bonzini <pbonzini@redhat.com>
      43bd9ef4
  6. 30 Jul, 2020 1 commit
  7. 10 Jul, 2020 1 commit
  8. 09 Jul, 2020 6 commits
  9. 08 Jul, 2020 4 commits
  10. 04 Jun, 2020 3 commits
  11. 01 Jun, 2020 2 commits
    • Like Xu's avatar
      KVM: x86/pmu: Support full width counting · 27461da3
      Like Xu authored
      
      Intel CPUs have a new alternative MSR range (starting from MSR_IA32_PMC0)
      for GP counters that allows writing the full counter width. Enable this
      range from a new capability bit (IA32_PERF_CAPABILITIES.FW_WRITE[bit 13]).
      
      The guest would query CPUID to get the counter width, and sign extends
      the counter values as needed. The traditional MSRs always limit to 32bit,
      even though the counter internally is larger (48 or 57 bits).
      
      When the new capability is set, use the alternative range which do not
      have these restrictions. This lowers the overhead of perf stat slightly
      because it has to do less interrupts to accumulate the counter value.
      Signed-off-by: default avatarLike Xu <like.xu@linux.intel.com>
      Message-Id: <20200529074347.124619-3-like.xu@linux.intel.com>
      Signed-off-by: default avatarPaolo Bonzini <pbonzini@redhat.com>
      27461da3
    • Vitaly Kuznetsov's avatar
      KVM: x86: announce KVM_FEATURE_ASYNC_PF_INT · 72de5fa4
      Vitaly Kuznetsov authored
      
      Introduce new capability to indicate that KVM supports interrupt based
      delivery of 'page ready' APF events. This includes support for both
      MSR_KVM_ASYNC_PF_INT and MSR_KVM_ASYNC_PF_ACK.
      Signed-off-by: default avatarVitaly Kuznetsov <vkuznets@redhat.com>
      Message-Id: <20200525144125.143875-8-vkuznets@redhat.com>
      Signed-off-by: default avatarPaolo Bonzini <pbonzini@redhat.com>
      72de5fa4
  12. 15 May, 2020 1 commit
  13. 13 May, 2020 1 commit
  14. 15 Apr, 2020 1 commit
  15. 31 Mar, 2020 2 commits
  16. 23 Mar, 2020 1 commit
  17. 18 Mar, 2020 3 commits
  18. 16 Mar, 2020 5 commits
    • Sean Christopherson's avatar
      KVM: x86: Refactor kvm_cpuid() param that controls out-of-range logic · f91af517
      Sean Christopherson authored
      
      Invert and rename the kvm_cpuid() param that controls out-of-range logic
      to better reflect the semantics of the affected callers, i.e. callers
      that bypass the out-of-range logic do so because they are looking up an
      exact guest CPUID entry, e.g. to query the maxphyaddr.
      
      Similarly, rename kvm_cpuid()'s internal "found" to "exact" to clarify
      that it tracks whether or not the exact requested leaf was found, as
      opposed to any usable leaf being found.
      
      No functional change intended.
      Signed-off-by: default avatarSean Christopherson <sean.j.christopherson@intel.com>
      Signed-off-by: default avatarPaolo Bonzini <pbonzini@redhat.com>
      f91af517
    • Sean Christopherson's avatar
      KVM: x86: Refactor out-of-range logic to contain the madness · 09c7431e
      Sean Christopherson authored
      
      Move all of the out-of-range logic into a single helper,
      get_out_of_range_cpuid_entry(), to avoid an extra lookup of CPUID.0.0
      and to provide a single location for documenting the out-of-range
      behavior.
      
      No functional change intended.
      
      Cc: Jim Mattson <jmattson@google.com>
      Signed-off-by: default avatarSean Christopherson <sean.j.christopherson@intel.com>
      Signed-off-by: default avatarPaolo Bonzini <pbonzini@redhat.com>
      09c7431e
    • Sean Christopherson's avatar
      KVM: x86: Fix CPUID range checks for Hypervisor and Centaur classes · 8d892311
      Sean Christopherson authored
      Rework the masking in the out-of-range CPUID logic to handle the
      Hypervisor sub-classes, as well as the Centaur class if the guest
      virtual CPU vendor is Centaur.
      
      Masking against 0x80000000 only handles basic and extended leafs, which
      results in Hypervisor range checks being performed against the basic
      CPUID class, and Centuar range checks being performed against the
      Extended class.  E.g. if CPUID.0x40000000.EAX returns 0x4000000A and
      there is no entry for CPUID.0x40000006, then function 0x40000006 would
      be incorrectly reported as out of bounds.
      
      While there is no official definition of what constitutes a class, the
      convention established for Hypervisor classes effectively uses bits 31:8
      as the mask by virtue of checking for different bases in increments of
      0x100, e.g. KVM advertises its CPUID functions starting at 0x40000100
      when HyperV features are advertised at the default base of 0x40000000.
      
      The bad range check doesn't cause functional problems for any known VMM
      because out-of-range semantics only come into play if the exact entry
      isn't found, and VMMs either support a very limited Hypervisor range,
      e.g. the official KVM range is 0x40000000-0x40000001 (effectively no
      room for undefined leafs) or explicitly defines gaps to be zero, e.g.
      Qemu explicitly creates zeroed entries up to the Centaur and Hypervisor
      limits (the latter comes into play when providing HyperV features).
      
      The bad behavior can be visually confirmed by dumping CPUID output in
      the guest when running Qemu with a stable TSC, as Qemu extends the limit
      of range 0x40000000 to 0x40000010 to advertise VMware's cpuid_freq,
      without defining zeroed entries for 0x40000002 - 0x4000000f.
      
      Note, documentation of Centaur/VIA CPUs is hard to come by.  Designating
      0xc0000000 - 0xcfffffff as the Centaur class is a best guess as to the
      behavior of a real Centaur/VIA CPU.
      
      Fixes: 43561123
      
       ("kvm: x86: Improve emulation of CPUID leaves 0BH and 1FH")
      Cc: Jim Mattson <jmattson@google.com>
      Signed-off-by: default avatarSean Christopherson <sean.j.christopherson@intel.com>
      Signed-off-by: default avatarPaolo Bonzini <pbonzini@redhat.com>
      8d892311
    • Sean Christopherson's avatar
      KVM x86: Extend AMD specific guest behavior to Hygon virtual CPUs · 23493d0a
      Sean Christopherson authored
      Extend guest_cpuid_is_amd() to cover Hygon virtual CPUs and rename it
      accordingly.  Hygon CPUs use an AMD-based core and so have the same
      basic behavior as AMD CPUs.
      
      Fixes: b8f4abb6
      
       ("x86/kvm: Add Hygon Dhyana support to KVM")
      Cc: Pu Wen <puwen@hygon.cn>
      Signed-off-by: default avatarSean Christopherson <sean.j.christopherson@intel.com>
      Signed-off-by: default avatarPaolo Bonzini <pbonzini@redhat.com>
      23493d0a
    • Jan Kiszka's avatar
      KVM: x86: Trace the original requested CPUID function in kvm_cpuid() · b7fb8488
      Jan Kiszka authored
      Trace the requested CPUID function instead of the effective function,
      e.g. if the requested function is out-of-range and KVM is emulating an
      Intel CPU, as the intent of the tracepoint is to show if the output came
      from the actual leaf as opposed to the max basic leaf via redirection.
      
      Similarly, leave "found" as is, i.e. report that an entry was found if
      and only if the requested entry was found.
      
      Fixes: 43561123
      
       ("kvm: x86: Improve emulation of CPUID leaves 0BH and 1FH")
      Signed-off-by: default avatarJan Kiszka <jan.kiszka@siemens.com>
      [Sean: Drop "found" semantic change, reword changelong accordingly ]
      Signed-off-by: default avatarSean Christopherson <sean.j.christopherson@intel.com>
      Signed-off-by: default avatarPaolo Bonzini <pbonzini@redhat.com>
      b7fb8488