1. 30 Jan, 2024 4 commits
    • Sean Christopherson's avatar
      KVM: x86/pmu: Setup fixed counters' eventsel during PMU initialization · 61bb2ad7
      Sean Christopherson authored
      Set the eventsel for all fixed counters during PMU initialization, the
      eventsel is hardcoded and consumed if and only if the counter is supported,
      i.e. there is no reason to redo the setup every time the PMU is refreshed.
      
      Configuring all KVM-supported fixed counter also eliminates a potential
      pitfall if/when KVM supports discontiguous fixed counters, in which case
      configuring only nr_arch_fixed_counters will be insufficient (ignoring the
      fact that KVM will need many other changes to support discontiguous fixed
      counters).
      Tested-by: default avatarDapeng Mi <dapeng1.mi@linux.intel.com>
      Link: https://lore.kernel.org/r/20240109230250.424295-5-seanjc@google.comSigned-off-by: default avatarSean Christopherson <seanjc@google.com>
      61bb2ad7
    • Sean Christopherson's avatar
      KVM: x86/pmu: Remove KVM's enumeration of Intel's architectural encodings · db9e008a
      Sean Christopherson authored
      Drop KVM's enumeration of Intel's architectural event encodings, and
      instead open code the three encodings (of which only two are real) that
      KVM uses to emulate fixed counters.  Now that KVM doesn't incorrectly
      enforce the availability of architectural encodings, there is no reason
      for KVM to ever care about the encodings themselves, at least not in the
      current format of an array indexed by the encoding's position in CPUID.
      
      Opportunistically add a comment to explain why KVM cares about eventsel
      values for fixed counters.
      Suggested-by: default avatarJim Mattson <jmattson@google.com>
      Tested-by: default avatarDapeng Mi <dapeng1.mi@linux.intel.com>
      Link: https://lore.kernel.org/r/20240109230250.424295-4-seanjc@google.comSigned-off-by: default avatarSean Christopherson <seanjc@google.com>
      db9e008a
    • Sean Christopherson's avatar
      KVM: x86/pmu: Allow programming events that match unsupported arch events · cbbd1aa8
      Sean Christopherson authored
      Remove KVM's bogus restriction that the guest can't program an event whose
      encoding matches an unsupported architectural event.  The enumeration of
      an architectural event only says that if a CPU supports an architectural
      event, then the event can be programmed using the architectural encoding.
      The enumeration does NOT say anything about the encoding when the CPU
      doesn't report support the architectural event.
      
      Preventing the guest from counting events whose encoding happens to match
      an architectural event breaks existing functionality whenever Intel adds
      an architectural encoding that was *ever* used for a CPU that doesn't
      enumerate support for the architectural event, even if the encoding is for
      the exact same event!
      
      E.g. the architectural encoding for Top-Down Slots is 0x01a4.  Broadwell
      CPUs, which do not support the Top-Down Slots architectural event, 0x01a4
      is a valid, model-specific event.  Denying guest usage of 0x01a4 if/when
      KVM adds support for Top-Down slots would break any Broadwell-based guest.
      Reported-by: default avatarKan Liang <kan.liang@linux.intel.com>
      Closes: https://lore.kernel.org/all/2004baa6-b494-462c-a11f-8104ea152c6a@linux.intel.com
      Fixes: a2186448 ("KVM: x86/pmu: Fix available_event_types check for REF_CPU_CYCLES event")
      Reviewed-by: default avatarDapeng Mi <dapeng1.mi@linux.intel.com>
      Reviewed-by: default avatarJim Mattson <jmattson@google.com>
      Reviewed-by: default avatarKan Liang <kan.liang@linux.intel.com>
      Tested-by: default avatarDapeng Mi <dapeng1.mi@linux.intel.com>
      Link: https://lore.kernel.org/r/20240109230250.424295-3-seanjc@google.comSigned-off-by: default avatarSean Christopherson <seanjc@google.com>
      cbbd1aa8
    • Sean Christopherson's avatar
      KVM: x86/pmu: Always treat Fixed counters as available when supported · 5eb7fcbd
      Sean Christopherson authored
      Treat fixed counters as available when they are supported, i.e. don't
      silently ignore an enabled fixed counter just because guest CPUID says the
      associated general purpose architectural event is unavailable.
      
      KVM originally treated fixed counters as always available, but that got
      changed as part of a fix to avoid confusing REF_CPU_CYCLES, which does NOT
      map to an architectural event, with the actual architectural event used
      associated with bit 7, TOPDOWN_SLOTS.
      
      The commit justified the change with:
      
          If the event is marked as unavailable in the Intel guest CPUID
          0AH.EBX leaf, we need to avoid any perf_event creation, whether
          it's a gp or fixed counter.
      
      but that justification doesn't mesh with reality.  The Intel SDM uses
      "architectural events" to refer to both general purpose events (the ones
      with the reverse polarity mask in CPUID.0xA.EBX) and the events for fixed
      counters, e.g. the SDM makes statements like:
      
        Each of the fixed-function PMC can count only one architectural
        performance event.
      
      but the fact that fixed counter 2 (TSC reference cycles) doesn't have an
      associated general purpose architectural makes trying to apply the mask
      from CPUID.0xA.EBX impossible.
      
      Furthermore, the lack of enumeration for an architectural event in CPUID
      only means the CPU doesn't officially support the architectural encoding,
      i.e. it doesn't mean using the architectural encoding _won't_ work, it
      sipmly means there are no guarantees that it will work as expected.  E.g.
      if KVM is running in a VM that advertises a fixed counters but not the
      corresponding architectural event encoding, and perf decides to use a
      general purpose counter instead of a fixed counter, odds are very good
      that the underlying hardware actually does support the architectrual
      encoding, and that programming the encoding will count the right thing.
      
      In other words, asking perf to count the event will probably work, whereas
      intentionally doing nothing is obviously guaranteed to fail.
      
      Note, at the time of the change, KVM didn't enforce hardware support, i.e.
      didn't prevent userspace from enumerating support in guest CPUID.0xA.EBX
      for architectural events that aren't supported in hardware.  I.e. silently
      dropping the fixed counter didn't somehow protection against counting the
      wrong event, it just enforced guest CPUID.  And practically speaking, this
      issue is almost certainly limited to running KVM on a funky virtual CPU
      model.  No known real hardware has an asymmetric PMU where a fixed counter
      is supported but the associated architectural event is not.
      
      Fixes: a2186448 ("KVM: x86/pmu: Fix available_event_types check for REF_CPU_CYCLES event")
      Tested-by: default avatarDapeng Mi <dapeng1.mi@linux.intel.com>
      Link: https://lore.kernel.org/r/20240109230250.424295-2-seanjc@google.comSigned-off-by: default avatarSean Christopherson <seanjc@google.com>
      5eb7fcbd
  2. 29 Jan, 2024 1 commit
  3. 28 Jan, 2024 7 commits
  4. 27 Jan, 2024 9 commits
  5. 26 Jan, 2024 19 commits