From: Sean Christopherson <seanjc@google.com>
To: Jinrong Liang <ljr.kernel@gmail.com>
Cc: Paolo Bonzini <pbonzini@redhat.com>, Like Xu <likexu@tencent.com>,
David Matlack <dmatlack@google.com>,
Aaron Lewis <aaronlewis@google.com>,
Vitaly Kuznetsov <vkuznets@redhat.com>,
Wanpeng Li <wanpengli@tencent.com>,
Jinrong Liang <cloudliang@tencent.com>,
kvm@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v4 2/9] KVM: selftests: Extend this_pmu_has() and kvm_pmu_has() to check arch events
Date: Thu, 19 Oct 2023 16:31:45 -0700 [thread overview]
Message-ID: <ZTG8YdrL98MEYo-p@google.com> (raw)
In-Reply-To: <20230911114347.85882-3-cloudliang@tencent.com>
On Mon, Sep 11, 2023, Jinrong Liang wrote:
> From: Jinrong Liang <cloudliang@tencent.com>
>
> The kvm_x86_pmu_feature struct has been updated to use the more
> descriptive name "pmu_feature" instead of "anti_feature".
>
> Extend this_pmu_has() and kvm_pmu_has() functions to better support
> checking for Intel architectural events. Rename this_pmu_has() and
> kvm_pmu_has() to this_pmu_has_arch_event() and kvm_pmu_has_arch_event().
>
> Suggested-by: Sean Christopherson <seanjc@google.com>
> Signed-off-by: Jinrong Liang <cloudliang@tencent.com>
> ---
> .../selftests/kvm/include/x86_64/processor.h | 38 ++++++++++++++-----
> .../kvm/x86_64/pmu_event_filter_test.c | 2 +-
> 2 files changed, 29 insertions(+), 11 deletions(-)
>
> diff --git a/tools/testing/selftests/kvm/include/x86_64/processor.h b/tools/testing/selftests/kvm/include/x86_64/processor.h
> index 6b146e1c6736..ede433eb6541 100644
> --- a/tools/testing/selftests/kvm/include/x86_64/processor.h
> +++ b/tools/testing/selftests/kvm/include/x86_64/processor.h
> @@ -280,12 +280,12 @@ struct kvm_x86_cpu_property {
> * architectural event is supported.
> */
> struct kvm_x86_pmu_feature {
> - struct kvm_x86_cpu_feature anti_feature;
> + struct kvm_x86_cpu_feature pmu_feature;
Eh, looking at this with fresh eyes, let's just use a single character to keep
the line lengths as short as possible. There was value in the anti_feature name,
but pmu_feature doesn't add anything IMO.
> };
> #define KVM_X86_PMU_FEATURE(name, __bit) \
> ({ \
> struct kvm_x86_pmu_feature feature = { \
> - .anti_feature = KVM_X86_CPU_FEATURE(0xa, 0, EBX, __bit), \
> + .pmu_feature = KVM_X86_CPU_FEATURE(0xa, 0, EBX, __bit), \
This needs to take in the register (EBX vs. ECX) for this helper to be useful.
> }; \
> \
> feature; \
> @@ -681,12 +681,21 @@ static __always_inline bool this_cpu_has_p(struct kvm_x86_cpu_property property)
> return max_leaf >= property.function;
> }
>
> -static inline bool this_pmu_has(struct kvm_x86_pmu_feature feature)
> +static inline bool this_pmu_has_arch_event(struct kvm_x86_pmu_feature feature)
Why? I don't see the point. And it's confusing for fixed counters. Yeah, fixed
counters count architectural events, but the code is asking if a _counter_ is
supported, not if the associated event is supported. And the darn name gets too
long, too.
> {
> - uint32_t nr_bits = this_cpu_property(X86_PROPERTY_PMU_EBX_BIT_VECTOR_LENGTH);
> + uint32_t nr_bits;
>
> - return nr_bits > feature.anti_feature.bit &&
> - !this_cpu_has(feature.anti_feature);
> + if (feature.pmu_feature.reg == KVM_CPUID_EBX) {
> + nr_bits = this_cpu_property(X86_PROPERTY_PMU_EBX_BIT_VECTOR_LENGTH);
> + return nr_bits > feature.pmu_feature.bit &&
> + !this_cpu_has(feature.pmu_feature);
> + } else if (feature.pmu_feature.reg == KVM_CPUID_ECX) {
> + nr_bits = this_cpu_property(X86_PROPERTY_PMU_NR_FIXED_COUNTERS);
> + return nr_bits > feature.pmu_feature.bit ||
> + this_cpu_has(feature.pmu_feature);
> + } else {
> + TEST_FAIL("Invalid register in kvm_x86_pmu_feature");
This needs to be a GUEST_ASSERT(), as the primary usage is in the guest.
And again looking at this with fresh eyes, I'd rather do
uint32_t nr_bits;
if (feature.f.reg == KVM_CPUID_EBX) {
nr_bits = this_cpu_property(X86_PROPERTY_PMU_EBX_BIT_VECTOR_LENGTH);
return nr_bits > feature.f.bit && !this_cpu_has(feature.f);
}
GUEST_ASSERT(feature.f.reg == KVM_CPUID_ECX);
nr_bits = this_cpu_property(X86_PROPERTY_PMU_NR_FIXED_COUNTERS);
return nr_bits > feature.f.bit || this_cpu_has(feature.f);
so that the bogus register is printed out on failure.
> + }
> }
>
> static __always_inline uint64_t this_cpu_supported_xcr0(void)
> @@ -900,12 +909,21 @@ static __always_inline bool kvm_cpu_has_p(struct kvm_x86_cpu_property property)
> return max_leaf >= property.function;
> }
>
> -static inline bool kvm_pmu_has(struct kvm_x86_pmu_feature feature)
> +static inline bool kvm_pmu_has_arch_event(struct kvm_x86_pmu_feature feature)
> {
> - uint32_t nr_bits = kvm_cpu_property(X86_PROPERTY_PMU_EBX_BIT_VECTOR_LENGTH);
> + uint32_t nr_bits;
>
> - return nr_bits > feature.anti_feature.bit &&
> - !kvm_cpu_has(feature.anti_feature);
> + if (feature.pmu_feature.reg == KVM_CPUID_EBX) {
> + nr_bits = kvm_cpu_property(X86_PROPERTY_PMU_EBX_BIT_VECTOR_LENGTH);
> + return nr_bits > feature.pmu_feature.bit &&
> + !kvm_cpu_has(feature.pmu_feature);
> + } else if (feature.pmu_feature.reg == KVM_CPUID_ECX) {
> + nr_bits = kvm_cpu_property(X86_PROPERTY_PMU_NR_FIXED_COUNTERS);
> + return nr_bits > feature.pmu_feature.bit ||
> + kvm_cpu_has(feature.pmu_feature);
> + } else {
> + TEST_FAIL("Invalid register in kvm_x86_pmu_feature");
Same thing here.
> + }
next prev parent reply other threads:[~2023-10-19 23:31 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-09-11 11:43 [PATCH v4 0/9] KVM: selftests: Test the consistency of the PMU's CPUID and its features Jinrong Liang
2023-09-11 11:43 ` [PATCH v4 1/9] KVM: selftests: Add vcpu_set_cpuid_property() to set properties Jinrong Liang
2023-10-19 23:28 ` Sean Christopherson
2023-09-11 11:43 ` [PATCH v4 2/9] KVM: selftests: Extend this_pmu_has() and kvm_pmu_has() to check arch events Jinrong Liang
2023-10-19 23:31 ` Sean Christopherson [this message]
2023-09-11 11:43 ` [PATCH v4 3/9] KVM: selftests: Add pmu.h for PMU events and common masks Jinrong Liang
2023-10-19 23:38 ` Sean Christopherson
2023-09-11 11:43 ` [PATCH v4 4/9] KVM: selftests: Test Intel PMU architectural events on gp counters Jinrong Liang
2023-10-19 23:39 ` Sean Christopherson
2023-09-11 11:43 ` [PATCH v4 5/9] KVM: selftests: Test Intel PMU architectural events on fixed counters Jinrong Liang
2023-10-19 23:55 ` Sean Christopherson
2023-09-11 11:43 ` [PATCH v4 6/9] KVM: selftests: Test consistency of CPUID with num of gp counters Jinrong Liang
2023-10-20 18:08 ` Sean Christopherson
2023-09-11 11:43 ` [PATCH v4 7/9] KVM: selftests: Test consistency of CPUID with num of fixed counters Jinrong Liang
2023-09-11 11:43 ` [PATCH v4 8/9] KVM: selftests: Test Intel supported fixed counters bit mask Jinrong Liang
2023-10-20 0:18 ` Sean Christopherson
2023-10-20 19:06 ` Sean Christopherson
2023-10-21 9:58 ` Jinrong Liang
2023-09-11 11:43 ` [PATCH v4 9/9] KVM: selftests: Test consistency of PMU MSRs with Intel PMU version Jinrong Liang
2023-10-11 8:32 ` [PATCH v4 0/9] KVM: selftests: Test the consistency of the PMU's CPUID and its features Jinrong Liang
2023-10-20 0:28 ` Sean Christopherson
2023-10-20 9:11 ` Jinrong Liang
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=ZTG8YdrL98MEYo-p@google.com \
--to=seanjc@google.com \
--cc=aaronlewis@google.com \
--cc=cloudliang@tencent.com \
--cc=dmatlack@google.com \
--cc=kvm@vger.kernel.org \
--cc=likexu@tencent.com \
--cc=linux-kernel@vger.kernel.org \
--cc=ljr.kernel@gmail.com \
--cc=pbonzini@redhat.com \
--cc=vkuznets@redhat.com \
--cc=wanpengli@tencent.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;
as well as URLs for NNTP newsgroup(s).