From: Sean Christopherson <seanjc@google.com>
To: Mingwei Zhang <mizhang@google.com>
Cc: Paolo Bonzini <pbonzini@redhat.com>,
kvm@vger.kernel.org, linux-kernel@vger.kernel.org,
Jinrong Liang <cloudliang@tencent.com>,
Like Xu <likexu@tencent.com>
Subject: Re: [PATCH v5 08/13] KVM: selftests: Test Intel PMU architectural events on gp counters
Date: Thu, 26 Oct 2023 15:54:55 -0700 [thread overview]
Message-ID: <ZTruPxjaU7NfrSOC@google.com> (raw)
In-Reply-To: <ZTrj1CRKLOVbcytz@google.com>
On Thu, Oct 26, 2023, Mingwei Zhang wrote:
> On Thu, Oct 26, 2023, Sean Christopherson wrote:
> > Heh, already did this too. Though I'm not entirely sure it's more readable. It's
> > definitely more precise and featured :-)
> >
> Oh dear, this is challenging to my rusty inline assembly skills :)
>
> > #define GUEST_MEASURE_EVENT(_msr, _value, clflush, FEP) \
> > do { \
> > __asm__ __volatile__("wrmsr\n\t" \
> > clflush "\n\t" \
> > "mfence\n\t" \
> > "1: mov $" __stringify(NUM_BRANCHES) ", %%ecx\n\t" \
> > FEP "loop .\n\t" \
> > FEP "mov %%edi, %%ecx\n\t" \
> > FEP "xor %%eax, %%eax\n\t" \
> > FEP "xor %%edx, %%edx\n\t" \
> > "wrmsr\n\t" \
> > : "+c"((int){_msr}) \
> isn't it NUM_BRANCHES?
Nope. It's hard to see because this doesn't provide the usage, but @_msr is an
MSR index that is consumed by the first "wrmsr", i.e. this blob relies on the
compiler to preload ECX, EAX, and EDX for WRMSR. NUM_BRANCHES is manually loaded
into ECX after WRMSR (WRMSR and LOOP both hardcode consuming ECX).
Ha! I can actually drop the "+c" clobbering trick since ECX is restored to its
input value before the asm blob finishes. EDI is also loaded with _@msr so that
it can be quickly reloaded into ECX for the WRMSR to disable the event.
The purpose of doing both WRMSRs in assembly is to ensure the compiler doesn't
insert _any_ code into the measured sequence, e.g. so that a random Jcc doesn't
throw off instructions retired.
> > : "a"((uint32_t)_value), "d"(_value >> 32), \
> > "D"(_msr) \
> > ); \
> > } while (0)
> >
>
> do we need this label '1:' in the above code? It does not seems to be
> used anywhere within the code.
It's used by the caller as the target for CLFLUSH{,OPT}.
if (this_cpu_has(X86_FEATURE_CLFLUSHOPT)) \
GUEST_MEASURE_EVENT(_ctrl_msr, _value, "clflushopt 1f", FEP); \
else if (this_cpu_has(X86_FEATURE_CLFLUSH)) \
GUEST_MEASURE_EVENT(_ctrl_msr, _value, "clflushopt 1f", FEP); \
else \
GUEST_MEASURE_EVENT(_ctrl_msr, _value, "nop", FEP); \
>
> why is clflush needed here?
As suggested by Jim, it allows verifying LLC references and misses by forcing
the CPU to evict the cache line that holds the MOV at 1: (and likely holds most
of the asm blob).
next prev parent reply other threads:[~2023-10-26 22:55 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-10-24 0:26 [PATCH v5 00/13] KVM: x86/pmu: selftests: Fixes and new tests Sean Christopherson
2023-10-24 0:26 ` [PATCH v5 01/13] KVM: x86/pmu: Don't allow exposing unsupported architectural events Sean Christopherson
2023-10-24 0:26 ` [PATCH v5 02/13] KVM: x86/pmu: Don't enumerate support for fixed counters KVM can't virtualize Sean Christopherson
2023-10-24 0:26 ` [PATCH v5 03/13] KVM: x86/pmu: Always treat Fixed counters as available when supported Sean Christopherson
2023-10-24 0:26 ` [PATCH v5 04/13] KVM: selftests: Add vcpu_set_cpuid_property() to set properties Sean Christopherson
2023-10-24 0:26 ` [PATCH v5 05/13] KVM: selftests: Drop the "name" param from KVM_X86_PMU_FEATURE() Sean Christopherson
2023-10-24 0:26 ` [PATCH v5 06/13] KVM: selftests: Extend {kvm,this}_pmu_has() to support fixed counters Sean Christopherson
2023-10-24 0:26 ` [PATCH v5 07/13] KVM: selftests: Add pmu.h and lib/pmu.c for common PMU assets Sean Christopherson
2023-10-24 0:26 ` [PATCH v5 08/13] KVM: selftests: Test Intel PMU architectural events on gp counters Sean Christopherson
2023-10-24 19:49 ` Sean Christopherson
2023-10-24 21:00 ` Sean Christopherson
2023-10-25 3:17 ` JinrongLiang
2023-10-26 20:38 ` Mingwei Zhang
2023-10-26 20:54 ` Sean Christopherson
2023-10-26 22:10 ` Mingwei Zhang
2023-10-26 22:54 ` Sean Christopherson [this message]
2023-10-24 0:26 ` [PATCH v5 09/13] KVM: selftests: Test Intel PMU architectural events on fixed counters Sean Christopherson
2023-10-24 0:26 ` [PATCH v5 10/13] KVM: selftests: Test consistency of CPUID with num of gp counters Sean Christopherson
2023-10-24 0:26 ` [PATCH v5 11/13] KVM: selftests: Test consistency of CPUID with num of fixed counters Sean Christopherson
2023-10-24 11:40 ` JinrongLiang
2023-10-24 14:22 ` Sean Christopherson
2023-10-24 0:26 ` [PATCH v5 12/13] KVM: selftests: Add functional test for Intel's fixed PMU counters Sean Christopherson
2023-10-24 0:26 ` [PATCH v5 13/13] KVM: selftests: Extend PMU counters test to permute on vPMU version Sean Christopherson
2023-10-24 11:49 ` JinrongLiang
2023-10-24 14:23 ` 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=ZTruPxjaU7NfrSOC@google.com \
--to=seanjc@google.com \
--cc=cloudliang@tencent.com \
--cc=kvm@vger.kernel.org \
--cc=likexu@tencent.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mizhang@google.com \
--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