public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Sean Christopherson <seanjc@google.com>
To: Dapeng Mi <dapeng1.mi@linux.intel.com>
Cc: Jim Mattson <jmattson@google.com>,
	Paolo Bonzini <pbonzini@redhat.com>,
	kvm@vger.kernel.org, linux-kernel@vger.kernel.org,
	Kan Liang <kan.liang@linux.intel.com>,
	Jinrong Liang <cloudliang@tencent.com>,
	Like Xu <likexu@tencent.com>, Aaron Lewis <aaronlewis@google.com>
Subject: Re: [PATCH v6 03/20] KVM: x86/pmu: Don't enumerate arch events KVM doesn't support
Date: Tue, 7 Nov 2023 09:27:20 -0800	[thread overview]
Message-ID: <ZUpzeGnWtExCxhcS@google.com> (raw)
In-Reply-To: <2c804098-af2b-4f1d-a39f-eb42f58635d7@linux.intel.com>

On Tue, Nov 07, 2023, Dapeng Mi wrote:
> 
> On 11/4/2023 8:41 PM, Jim Mattson wrote:
> > On Fri, Nov 3, 2023 at 5:02 PM Sean Christopherson <seanjc@google.com> wrote:
> > > Don't advertise support to userspace for architectural events that KVM
> > > doesn't support, i.e. for "real" events that aren't listed in
> > > intel_pmu_architectural_events.  On current hardware, this effectively
> > > means "don't advertise support for Top Down Slots".
> > NR_REAL_INTEL_ARCH_EVENTS is only used in intel_hw_event_available().
> > As discussed (https://lore.kernel.org/kvm/ZUU12-TUR_1cj47u@google.com/),
> > intel_hw_event_available() should go away.
> > 
> > Aside from mapping fixed counters to event selector and unit mask
> > (fixed_pmc_events[]), KVM has no reason to know when a new
> > architectural event is defined.
> 
> 
> Since intel_hw_event_available() would be removed, it looks the enum
> intel_pmu_architectural_events and intel_arch_events[] array become useless.
> We can directly simply modify current fixed_pmc_events[] array and use it to
> store fixed counter events code and umask.

Yep, I came to the same conclusion.  This is what I ended up with yesterday:

/*
 * Map fixed counter events to architectural general purpose event encodings.
 * Perf doesn't provide APIs to allow KVM to directly program a fixed counter,
 * and so KVM instead programs the architectural event to effectively request
 * the fixed counter.  Perf isn't guaranteed to use a fixed counter and may
 * instead program the encoding into a general purpose counter, e.g. if a
 * different perf_event is already utilizing the requested counter, but the end
 * result is the same (ignoring the fact that using a general purpose counter
 * will likely exacerbate counter contention).
 *
 * Note, reference cycles is counted using a perf-defined "psuedo-encoding",
 * there is no architectural general purpose encoding for reference TSC cycles.
 */
static u64 intel_get_fixed_pmc_eventsel(int index)
{
        const struct {
                u8 eventsel;
                u8 unit_mask;
        } fixed_pmc_events[] = {
                [0] = { 0xc0, 0x00 }, /* Instruction Retired / PERF_COUNT_HW_INSTRUCTIONS. */
                [1] = { 0x3c, 0x00 }, /* CPU Cycles/ PERF_COUNT_HW_CPU_CYCLES. */
                [2] = { 0x00, 0x03 }, /* Reference TSC Cycles / PERF_COUNT_HW_REF_CPU_CYCLES*/
        };

        BUILD_BUG_ON(ARRAY_SIZE(fixed_pmc_events) != KVM_PMC_MAX_FIXED);

        return (fixed_pmc_events[index].unit_mask << 8) |
               fixed_pmc_events[index].eventsel;
}

...

static void intel_pmu_init(struct kvm_vcpu *vcpu)
{
        int i;
        struct kvm_pmu *pmu = vcpu_to_pmu(vcpu);
        struct lbr_desc *lbr_desc = vcpu_to_lbr_desc(vcpu);

        for (i = 0; i < KVM_INTEL_PMC_MAX_GENERIC; i++) {
                pmu->gp_counters[i].type = KVM_PMC_GP;
                pmu->gp_counters[i].vcpu = vcpu;
                pmu->gp_counters[i].idx = i;
                pmu->gp_counters[i].current_config = 0;
        }

        for (i = 0; i < KVM_PMC_MAX_FIXED; i++) {
                pmu->fixed_counters[i].type = KVM_PMC_FIXED;
                pmu->fixed_counters[i].vcpu = vcpu;
                pmu->fixed_counters[i].idx = i + INTEL_PMC_IDX_FIXED;
                pmu->fixed_counters[i].current_config = 0;
                pmu->fixed_counters[i].eventsel = intel_get_fixed_pmc_eventsel(i);
        }

        lbr_desc->records.nr = 0;
        lbr_desc->event = NULL;
        lbr_desc->msr_passthrough = false;
}



  reply	other threads:[~2023-11-07 17:39 UTC|newest]

Thread overview: 43+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-11-04  0:02 [PATCH v6 00/20] KVM: x86/pmu: selftests: Fixes and new tests Sean Christopherson
2023-11-04  0:02 ` [PATCH v6 01/20] KVM: x86/pmu: Don't allow exposing unsupported architectural events Sean Christopherson
2023-11-04 12:08   ` Jim Mattson
2023-11-06 14:43     ` Sean Christopherson
2023-11-04  0:02 ` [PATCH v6 02/20] KVM: x86/pmu: Don't enumerate support for fixed counters KVM can't virtualize Sean Christopherson
2023-11-04 12:25   ` Jim Mattson
2023-11-06 15:31     ` Sean Christopherson
2023-11-04  0:02 ` [PATCH v6 03/20] KVM: x86/pmu: Don't enumerate arch events KVM doesn't support Sean Christopherson
2023-11-04 12:41   ` Jim Mattson
2023-11-07  7:14     ` Mi, Dapeng
2023-11-07 17:27       ` Sean Christopherson [this message]
2023-11-04  0:02 ` [PATCH v6 04/20] KVM: x86/pmu: Always treat Fixed counters as available when supported Sean Christopherson
2023-11-04 12:43   ` Jim Mattson
2023-11-04  0:02 ` [PATCH v6 05/20] KVM: x86/pmu: Allow programming events that match unsupported arch events Sean Christopherson
2023-11-04 12:46   ` Jim Mattson
2023-11-07  7:15   ` Mi, Dapeng
2023-11-04  0:02 ` [PATCH v6 06/20] KVM: selftests: Add vcpu_set_cpuid_property() to set properties Sean Christopherson
2023-11-04 12:51   ` Jim Mattson
2023-11-06 19:01     ` Sean Christopherson
2023-11-04  0:02 ` [PATCH v6 07/20] KVM: selftests: Drop the "name" param from KVM_X86_PMU_FEATURE() Sean Christopherson
2023-11-04 12:52   ` Jim Mattson
2023-11-04  0:02 ` [PATCH v6 08/20] KVM: selftests: Extend {kvm,this}_pmu_has() to support fixed counters Sean Christopherson
2023-11-04 13:00   ` Jim Mattson
2023-11-06 19:50     ` Sean Christopherson
2023-11-04  0:02 ` [PATCH v6 09/20] KVM: selftests: Add pmu.h and lib/pmu.c for common PMU assets Sean Christopherson
2023-11-04 13:20   ` Jim Mattson
2023-11-06  7:19     ` JinrongLiang
2023-11-06 20:40       ` Sean Christopherson
2023-11-07 10:51         ` Jinrong Liang
2023-11-04  0:02 ` [PATCH v6 10/20] KVM: selftests: Test Intel PMU architectural events on gp counters Sean Christopherson
2023-11-04 13:29   ` Jim Mattson
2023-11-04  0:02 ` [PATCH v6 11/20] KVM: selftests: Test Intel PMU architectural events on fixed counters Sean Christopherson
2023-11-04 13:46   ` Jim Mattson
2023-11-06 16:39     ` Sean Christopherson
2023-11-04  0:02 ` [PATCH v6 12/20] KVM: selftests: Test consistency of CPUID with num of gp counters Sean Christopherson
2023-11-04  0:02 ` [PATCH v6 13/20] KVM: selftests: Test consistency of CPUID with num of fixed counters Sean Christopherson
2023-11-04  0:02 ` [PATCH v6 14/20] KVM: selftests: Add functional test for Intel's fixed PMU counters Sean Christopherson
2023-11-04  0:02 ` [PATCH v6 15/20] KVM: selftests: Expand PMU counters test to verify LLC events Sean Christopherson
2023-11-04  0:02 ` [PATCH v6 16/20] KVM: selftests: Add a helper to query if the PMU module param is enabled Sean Christopherson
2023-11-04  0:02 ` [PATCH v6 17/20] KVM: selftests: Add helpers to read integer module params Sean Christopherson
2023-11-04  0:02 ` [PATCH v6 18/20] KVM: selftests: Query module param to detect FEP in MSR filtering test Sean Christopherson
2023-11-04  0:02 ` [PATCH v6 19/20] KVM: selftests: Move KVM_FEP macro into common library header Sean Christopherson
2023-11-04  0:02 ` [PATCH v6 20/20] KVM: selftests: Test PMC virtualization with forced emulation Sean Christopherson

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=ZUpzeGnWtExCxhcS@google.com \
    --to=seanjc@google.com \
    --cc=aaronlewis@google.com \
    --cc=cloudliang@tencent.com \
    --cc=dapeng1.mi@linux.intel.com \
    --cc=jmattson@google.com \
    --cc=kan.liang@linux.intel.com \
    --cc=kvm@vger.kernel.org \
    --cc=likexu@tencent.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=pbonzini@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox