From: Sean Christopherson <seanjc@google.com>
To: Colton Lewis <coltonlewis@google.com>
Cc: kvm@vger.kernel.org, Mingwei Zhang <mizhang@google.com>,
Jinrong Liang <ljr.kernel@gmail.com>,
Jim Mattson <jmattson@google.com>,
Aaron Lewis <aaronlewis@google.com>,
Paolo Bonzini <pbonzini@redhat.com>,
Shuah Khan <shuah@kernel.org>,
linux-kselftest@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v2 5/6] KVM: x86: selftests: Test core events
Date: Wed, 8 Jan 2025 11:31:06 -0800 [thread overview]
Message-ID: <Z37Seos1zVHk0-p7@google.com> (raw)
In-Reply-To: <20240918205319.3517569-6-coltonlewis@google.com>
On Wed, Sep 18, 2024, Colton Lewis wrote:
> Test events on core counters by iterating through every combination of
> events in amd_pmu_zen_events with every core counter.
>
> For each combination, calculate the appropriate register addresses for
> the event selection/control register and the counter register. The
> base addresses and layout schemes change depending on whether we have
> the CoreExt feature.
>
> To do the testing, reuse GUEST_TEST_EVENT to run a standard known
> workload. Decouple it from guest_assert_event_count (now
> guest_assert_intel_event_count) to generalize to AMD.
>
> Then assert the most specific detail that can be reasonably known
> about the counter result. Exact count is defined and known for some
> events and for other events merely asserted to be nonzero.
>
> Note on exact counts: AMD counts one more branch than Intel for the
> same workload. Though I can't confirm a reason, the only thing it
> could be is the boundary of the loop instruction being counted
> differently. Presumably, when the counter reaches 0 and execution
> continues to the next instruction, AMD counts this as a branch and
> Intel doesn't
IIRC, VMRUN is counted as a branch instruction for the guest. Assuming my memory
is correct, that means this test is going to be flaky as an asynchronous exit,
e.g. due to a host IRQ, during the measurement loop will inflate the count. I'm
not entirely sure what to do about that :-(
> +static void __guest_test_core_event(uint8_t event_idx, uint8_t counter_idx)
> +{
> + /* One fortunate area of actual compatibility! This register
/*
* This is the proper format for multi-line comments. We are not the
* crazy net/ folks.
*/
> + * layout is the same for both AMD and Intel.
It's not, actually. There are differences in the layout, it just so happens that
the differences don't throw a wrench in things.
The comments in tools/testing/selftests/kvm/include/x86_64/pmu.h document this
fairly well, I don't see any reason to have a comment here.
> + */
> + uint64_t eventsel = ARCH_PERFMON_EVENTSEL_OS |
> + ARCH_PERFMON_EVENTSEL_ENABLE |
> + amd_pmu_zen_events[event_idx];
Align the indentation.
uint64_t eventsel = ARCH_PERFMON_EVENTSEL_OS |
ARCH_PERFMON_EVENTSEL_ENABLE |
amd_pmu_zen_events[event_idx];
> + bool core_ext = this_cpu_has(X86_FEATURE_PERF_CTR_EXT_CORE);
> + uint64_t esel_msr_base = core_ext ? MSR_F15H_PERF_CTL : MSR_K7_EVNTSEL0;
> + uint64_t cnt_msr_base = core_ext ? MSR_F15H_PERF_CTR : MSR_K7_PERFCTR0;
> + uint64_t msr_step = core_ext ? 2 : 1;
> + uint64_t esel_msr = esel_msr_base + msr_step * counter_idx;
> + uint64_t cnt_msr = cnt_msr_base + msr_step * counter_idx;
This pattern of code is copy+pasted in three functions. Please add macros and/or
helpers to consolidate things. These should also be uint32_t, not 64.
It's a bit evil, but one approach would be to add a macro to iterate over all
PMU counters. Eating the VM-Exit for the CPUID to get X86_FEATURE_PERF_CTR_EXT_CORE
each time is unfortunate, but I doubt/hope it's not problematic in practice. If
the cost is meaningful, we could figure out a way to cache the info, e.g. something
awful like this might work:
/* Note, this relies on guest state being recreated between each test. */
static int has_perfctr_core = -1;
if (has_perfctr_core == -1)
has_perfctr_core = this_cpu_has(X86_FEATURE_PERFCTR_CORE);
if (has_perfctr_core) {
static bool get_pmu_counter_msrs(int idx, uint32_t *eventsel, uint32_t *pmc)
{
if (this_cpu_has(X86_FEATURE_PERFCTR_CORE)) {
*eventsel = MSR_F15H_PERF_CTL + idx * 2;
*pmc = MSR_F15H_PERF_CTR + idx * 2;
} else {
*eventsel = MSR_K7_EVNTSEL0 + idx;
*pmc = MSR_K7_PERFCTR0 + idx;
}
return true;
}
#define for_each_pmu_counter(_i, _nr_counters, _eventsel, _pmc) \
for (_i = 0; i < _nr_counters; _i++) \
if (get_pmu_counter_msrs(_i, &_eventsel, _pmc)) \
static void guest_test_core_events(void)
{
uint8_t nr_counters = guest_nr_core_counters();
uint32_t eventsel_msr, pmc_msr;
int i, j;
for (i = 0; i < NR_AMD_ZEN_EVENTS; i++) {
for_each_pmu_counter(j, nr_counters, eventsel_msr, pmc_msr) {
uint64_t eventsel = ARCH_PERFMON_EVENTSEL_OS |
ARCH_PERFMON_EVENTSEL_ENABLE |
amd_pmu_zen_events[event_idx];
GUEST_TEST_EVENT(pmc_msr, eventsel_msr, eventsel, "");
guest_assert_amd_event_count(i, j, pmc_msr);
if (!is_forced_emulation_enabled)
continue;
GUEST_TEST_EVENT(pmc_msr, eventsel_msr, eventsel, KVM_FEP);
guest_assert_amd_event_count(i, j, pmc_msr);
}
}
}
next prev parent reply other threads:[~2025-01-08 19:31 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-09-18 20:53 [PATCH v2 0/6] Extend pmu_counters_test to AMD CPUs Colton Lewis
2024-09-18 20:53 ` [PATCH v2 1/6] KVM: x86: selftests: Fix typos in macro variable use Colton Lewis
2024-09-18 20:53 ` [PATCH v2 2/6] KVM: x86: selftests: Define AMD PMU CPUID leaves Colton Lewis
2025-01-08 17:58 ` Sean Christopherson
2025-01-20 17:06 ` Colton Lewis
2024-09-18 20:53 ` [PATCH v2 3/6] KVM: x86: selftests: Set up AMD VM in pmu_counters_test Colton Lewis
2025-01-08 18:35 ` Sean Christopherson
2025-01-20 18:03 ` Colton Lewis
2025-01-21 20:56 ` Sean Christopherson
2024-09-18 20:53 ` [PATCH v2 4/6] KVM: x86: selftests: Test read/write core counters Colton Lewis
2025-01-08 18:54 ` Sean Christopherson
2025-01-20 19:54 ` Colton Lewis
2024-09-18 20:53 ` [PATCH v2 5/6] KVM: x86: selftests: Test core events Colton Lewis
2025-01-08 19:31 ` Sean Christopherson [this message]
2025-01-20 20:01 ` Colton Lewis
2024-09-18 20:53 ` [PATCH v2 6/6] KVM: x86: selftests: Test PerfMonV2 Colton Lewis
2025-01-08 19:42 ` Sean Christopherson
2025-01-20 20:07 ` Colton Lewis
2024-10-31 20:09 ` [PATCH v2 0/6] Extend pmu_counters_test to AMD CPUs Colton Lewis
2025-01-09 19:47 ` Sean Christopherson
2025-01-20 20:11 ` Colton Lewis
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=Z37Seos1zVHk0-p7@google.com \
--to=seanjc@google.com \
--cc=aaronlewis@google.com \
--cc=coltonlewis@google.com \
--cc=jmattson@google.com \
--cc=kvm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-kselftest@vger.kernel.org \
--cc=ljr.kernel@gmail.com \
--cc=mizhang@google.com \
--cc=pbonzini@redhat.com \
--cc=shuah@kernel.org \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.