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 v3 05/11] KVM: selftests: Test consistency of CPUID with num of gp counters
Date: Thu, 17 Aug 2023 16:18:20 -0700 [thread overview]
Message-ID: <ZN6qvKnltoyzbzDW@google.com> (raw)
In-Reply-To: <ZN6mfSWLScLjdyCz@google.com>
On Thu, Aug 17, 2023, Sean Christopherson wrote:
> On Mon, Aug 14, 2023, Jinrong Liang wrote:
> > From: Jinrong Liang <cloudliang@tencent.com>
> >
> > Add test to check if non-existent counters can be accessed in guest after
> > determining the number of Intel generic performance counters by CPUID.
> > When the num of counters is less than 3, KVM does not emulate #GP if
> > a counter isn't present due to compatibility MSR_P6_PERFCTRx handling.
> > Nor will the KVM emulate more counters than it can support.
> >
> > Co-developed-by: Like Xu <likexu@tencent.com>
> > Signed-off-by: Like Xu <likexu@tencent.com>
> > Signed-off-by: Jinrong Liang <cloudliang@tencent.com>
> > ---
> > .../kvm/x86_64/pmu_basic_functionality_test.c | 78 +++++++++++++++++++
> > 1 file changed, 78 insertions(+)
> >
> > diff --git a/tools/testing/selftests/kvm/x86_64/pmu_basic_functionality_test.c b/tools/testing/selftests/kvm/x86_64/pmu_basic_functionality_test.c
> > index daa45aa285bb..b86033e51d5c 100644
> > --- a/tools/testing/selftests/kvm/x86_64/pmu_basic_functionality_test.c
> > +++ b/tools/testing/selftests/kvm/x86_64/pmu_basic_functionality_test.c
> > @@ -16,6 +16,11 @@
> > /* Guest payload for any performance counter counting */
> > #define NUM_BRANCHES 10
> >
> > +static const uint64_t perf_caps[] = {
> > + 0,
> > + PMU_CAP_FW_WRITES,
> > +};
> > +
> > static struct kvm_vm *pmu_vm_create_with_one_vcpu(struct kvm_vcpu **vcpu,
> > void *guest_code)
> > {
> > @@ -164,6 +169,78 @@ static void intel_test_arch_events(void)
> > }
> > }
> >
> > +static void guest_wr_and_rd_msrs(uint32_t base, uint8_t begin, uint8_t offset)
> > +{
> > + uint8_t wr_vector, rd_vector;
> > + uint64_t msr_val;
> > + unsigned int i;
> > +
> > + for (i = begin; i < begin + offset; i++) {
> > + wr_vector = wrmsr_safe(base + i, 0xffff);
> > + rd_vector = rdmsr_safe(base + i, &msr_val);
Unless I'm missing something, there is zero reason to pass "base" and "being"
separately, just do the math in the host. A "base" that isn't actually the base
when viewed without the full context is super confusing.
> > + if (wr_vector == GP_VECTOR || rd_vector == GP_VECTOR)
> > + GUEST_SYNC(GP_VECTOR);
>
> Rather than pass around the "expected" vector, and shuffle #GP vs. the msr_val
> up (which can get false negatives if msr_val == 13), just read
> MSR_IA32_PERF_CAPABILITIES from within the guest and GUEST_ASSERT accordingly.
Ah, you did that so that the fixed counter test can reuse the guest code. Just
use separate trampolines in the guest, e.g.
static void __guest_wrmsr_rdmsr(uint32_t base, uint8_t nr_msrs, bool expect_gp)
{
uint64_t msr_val;
uint8_t vector;
uint32_t i;
for (i = base; i < base + nr_msrs; i++) {
vector = wrmsr_safe(i, 0xffff);
GUEST_ASSERT(expect_gp ? vector == GP_VECTOR : !vector,
"...");
vector = rdmsr_safe(i, &msr_val);
GUEST_ASSERT(expect_gp ? vector == GP_VECTOR : !vector,
"...");
if (!expect_gp)
GUEST_ASSERT_EQ(msr_val, 0);
}
GUEST_DONE();
}
static void guest_rd_wr_fixed_counter(uint32_t base, uint8_t nr_msrs)
{
__guest_wrmsr_rdmsr(base, nr_msrs, true);
}
static void guest_rd_wr_gp_counter(uint32_t base, uint8_t nr_msrs)
{
uint64_t perf_capabilities = rdmsr();
__guest_wrmsr_rdmsr(base, nr_msrs, !!perf_capabilities);
}
next prev parent reply other threads:[~2023-08-17 23:19 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-08-14 11:50 [PATCH v3 00/11] KVM: selftests: Test the consistency of the PMU's CPUID and its features Jinrong Liang
2023-08-14 11:50 ` [PATCH v3 01/11] KVM: selftests: Add vcpu_set_cpuid_property() to set properties Jinrong Liang
2023-08-14 11:50 ` [PATCH v3 02/11] KVM: selftests: Add pmu.h for PMU events and common masks Jinrong Liang
2023-08-17 22:32 ` Sean Christopherson
2023-08-21 8:56 ` Like Xu
2023-08-21 9:07 ` Jinrong Liang
2023-08-14 11:51 ` [PATCH v3 03/11] KVM: selftests: Test Intel PMU architectural events on gp counters Jinrong Liang
2023-08-17 22:46 ` Sean Christopherson
2023-08-17 22:54 ` Sean Christopherson
2023-08-21 11:45 ` Jinrong Liang
2023-08-14 11:51 ` [PATCH v3 04/11] KVM: selftests: Test Intel PMU architectural events on fixed counters Jinrong Liang
2023-08-17 22:56 ` Sean Christopherson
2023-08-14 11:51 ` [PATCH v3 05/11] KVM: selftests: Test consistency of CPUID with num of gp counters Jinrong Liang
2023-08-17 23:00 ` Sean Christopherson
2023-08-17 23:18 ` Sean Christopherson [this message]
2023-08-14 11:51 ` [PATCH v3 06/11] KVM: selftests: Test consistency of CPUID with num of fixed counters Jinrong Liang
2023-08-17 23:04 ` Sean Christopherson
2023-08-14 11:51 ` [PATCH v3 07/11] KVM: selftests: Test Intel supported fixed counters bit mask Jinrong Liang
2023-08-17 23:19 ` Sean Christopherson
2023-08-14 11:51 ` [PATCH v3 08/11] KVM: selftests: Test consistency of PMU MSRs with Intel PMU version Jinrong Liang
2023-08-17 23:21 ` Sean Christopherson
2023-08-14 11:51 ` [PATCH v3 09/11] KVM: selftests: Add x86 feature and properties for AMD PMU in processor.h Jinrong Liang
2023-08-17 23:26 ` Sean Christopherson
2023-08-14 11:51 ` [PATCH v3 10/11] KVM: selftests: Test AMD PMU events on legacy four performance counters Jinrong Liang
2023-08-14 11:51 ` [PATCH v3 11/11] KVM: selftests: Test AMD Guest PerfMonV2 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=ZN6qvKnltoyzbzDW@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 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.