From: Like Xu <like.xu.linux@gmail.com>
To: Jim Mattson <jmattson@google.com>, Paolo Bonzini <pbonzini@redhat.com>
Cc: kvm@vger.kernel.org, Sean Christopherson <seanjc@google.com>,
Wanpeng Li <wanpengli@tencent.com>,
Vitaly Kuznetsov <vkuznets@redhat.com>,
Joerg Roedel <joro@8bytes.org>,
linux-kernel@vger.kernel.org, Like Xu <likexu@tencent.com>,
Peter Zijlstra <peterz@infradead.org>
Subject: Re: [PATCH v2 07/12] KVM: x86/pmu: Use PERF_TYPE_RAW to merge reprogram_{gp, fixed}counter()
Date: Tue, 8 Mar 2022 19:43:59 +0800 [thread overview]
Message-ID: <888d5878-a2be-4624-d2c5-227fa19c8150@gmail.com> (raw)
In-Reply-To: <CALMp9eQtzS6HEHZ4__K9VuG+-Duwt5uUFb_FcW4DaBKPDmcYkA@mail.gmail.com>
On 8/3/2022 8:36 am, Jim Mattson wrote:
> On Wed, Mar 2, 2022 at 3:14 AM Like Xu <like.xu.linux@gmail.com> wrote:
>>
>> From: Like Xu <likexu@tencent.com>
>>
>> The code sketch for reprogram_{gp, fixed}_counter() is similar, while the
>> fixed counter using the PERF_TYPE_HARDWAR type and the gp being
>> able to use either PERF_TYPE_HARDWAR or PERF_TYPE_RAW type
>> depending on the pmc->eventsel value.
>>
>> After 'commit 761875634a5e ("KVM: x86/pmu: Setup pmc->eventsel
>> for fixed PMCs")', the pmc->eventsel of the fixed counter will also have
>> been setup with the same semantic value and will not be changed during
>> the guest runtime. But essentially, "the HARDWARE is just a convenience
>> wrapper over RAW IIRC", quoated from Peterz. So it could be pretty safe
>> to use the PERF_TYPE_RAW type only to program both gp and fixed
>> counters naturally in the reprogram_counter().
>>
>> To make the gp and fixed counters more semantically symmetrical,
>> the selection of EVENTSEL_{USER, OS, INT} bits is temporarily translated
>> via fixed_ctr_ctrl before the pmc_reprogram_counter() call.
>>
>> Cc: Peter Zijlstra <peterz@infradead.org>
>> Suggested-by: Jim Mattson <jmattson@google.com>
>> Signed-off-by: Like Xu <likexu@tencent.com>
>> ---
>> arch/x86/kvm/pmu.c | 128 +++++++++++++----------------------
>> arch/x86/kvm/vmx/pmu_intel.c | 2 +-
>> 2 files changed, 47 insertions(+), 83 deletions(-)
>>
>> diff --git a/arch/x86/kvm/pmu.c b/arch/x86/kvm/pmu.c
>> index 5299488b002c..00e1660c10ca 100644
>> --- a/arch/x86/kvm/pmu.c
>> +++ b/arch/x86/kvm/pmu.c
>> @@ -215,85 +215,60 @@ static bool check_pmu_event_filter(struct kvm_pmc *pmc)
>> return allow_event;
>> }
>>
>> -static void reprogram_gp_counter(struct kvm_pmc *pmc)
>> -{
>> - u64 config;
>> - u32 type = PERF_TYPE_RAW;
>> - u64 eventsel = pmc->eventsel;
>> -
>> - if (eventsel & ARCH_PERFMON_EVENTSEL_PIN_CONTROL)
>> - printk_once("kvm pmu: pin control bit is ignored\n");
>> -
>> - pmc_pause_counter(pmc);
>> -
>> - if (!(eventsel & ARCH_PERFMON_EVENTSEL_ENABLE) || !pmc_is_enabled(pmc))
>> - return;
>> -
>> - if (!check_pmu_event_filter(pmc))
>> - return;
>> -
>> - if (!(eventsel & (ARCH_PERFMON_EVENTSEL_EDGE |
>> - ARCH_PERFMON_EVENTSEL_INV |
>> - ARCH_PERFMON_EVENTSEL_CMASK |
>> - HSW_IN_TX |
>> - HSW_IN_TX_CHECKPOINTED))) {
>> - config = kvm_x86_ops.pmu_ops->pmc_perf_hw_id(pmc);
>> - if (config != PERF_COUNT_HW_MAX)
>> - type = PERF_TYPE_HARDWARE;
>> - }
>> -
>> - if (type == PERF_TYPE_RAW)
>> - config = eventsel & AMD64_RAW_EVENT_MASK;
>> -
>> - if (pmc->current_config == eventsel && pmc_resume_counter(pmc))
>> - return;
>> -
>> - pmc_release_perf_event(pmc);
>> -
>> - pmc->current_config = eventsel;
>> - pmc_reprogram_counter(pmc, type, config,
>> - !(eventsel & ARCH_PERFMON_EVENTSEL_USR),
>> - !(eventsel & ARCH_PERFMON_EVENTSEL_OS),
>> - eventsel & ARCH_PERFMON_EVENTSEL_INT,
>> - (eventsel & HSW_IN_TX),
>> - (eventsel & HSW_IN_TX_CHECKPOINTED));
>> -}
>> -
>> -static void reprogram_fixed_counter(struct kvm_pmc *pmc)
>> +static inline bool pmc_speculative_in_use(struct kvm_pmc *pmc)
>> {
>> struct kvm_pmu *pmu = pmc_to_pmu(pmc);
>> - int idx = pmc->idx - INTEL_PMC_IDX_FIXED;
>> - u8 ctrl = fixed_ctrl_field(pmu->fixed_ctr_ctrl, idx);
>> - unsigned en_field = ctrl & 0x3;
>> - bool pmi = ctrl & 0x8;
>>
>> - pmc_pause_counter(pmc);
>> + if (pmc_is_fixed(pmc))
>> + return fixed_ctrl_field(pmu->fixed_ctr_ctrl,
>> + pmc->idx - INTEL_PMC_IDX_FIXED) & 0x3;
>>
>> - if (!en_field || !pmc_is_enabled(pmc))
>> - return;
>> -
>> - if (!check_pmu_event_filter(pmc))
>> - return;
>> -
>> - if (pmc->current_config == (u64)ctrl && pmc_resume_counter(pmc))
>> - return;
>> -
>> - pmc_release_perf_event(pmc);
>> -
>> - pmc->current_config = (u64)ctrl;
>> - pmc_reprogram_counter(pmc, PERF_TYPE_HARDWARE,
>> - kvm_x86_ops.pmu_ops->pmc_perf_hw_id(pmc),
>> - !(en_field & 0x2), /* exclude user */
>> - !(en_field & 0x1), /* exclude kernel */
>> - pmi, false, false);
>> + return pmc->eventsel & ARCH_PERFMON_EVENTSEL_ENABLE;
>> }
>>
>> void reprogram_counter(struct kvm_pmc *pmc)
>> {
>> - if (pmc_is_gp(pmc))
>> - reprogram_gp_counter(pmc);
>> - else
>> - reprogram_fixed_counter(pmc);
>> + struct kvm_pmu *pmu = pmc_to_pmu(pmc);
>> + u64 eventsel = pmc->eventsel;
>> + u64 new_config = eventsel;
>> + u8 fixed_ctr_ctrl;
>> +
>> + pmc_pause_counter(pmc);
>> +
>> + if (!pmc_speculative_in_use(pmc) || !pmc_is_enabled(pmc))
>> + return;
>> +
>> + if (!check_pmu_event_filter(pmc))
>> + return;
>> +
>> + if (eventsel & ARCH_PERFMON_EVENTSEL_PIN_CONTROL)
>> + printk_once("kvm pmu: pin control bit is ignored\n");
>> +
>> + if (pmc_is_fixed(pmc)) {
>> + fixed_ctr_ctrl = fixed_ctrl_field(pmu->fixed_ctr_ctrl,
>> + pmc->idx - INTEL_PMC_IDX_FIXED);
>> + if (fixed_ctr_ctrl & 0x1)
>> + eventsel |= ARCH_PERFMON_EVENTSEL_OS;
>> + if (fixed_ctr_ctrl & 0x2)
>> + eventsel |= ARCH_PERFMON_EVENTSEL_USR;
>> + if (fixed_ctr_ctrl & 0x8)
>> + eventsel |= ARCH_PERFMON_EVENTSEL_INT;
>> + new_config = (u64)fixed_ctr_ctrl;
>> + }
>> +
>> + if (pmc->current_config == new_config && pmc_resume_counter(pmc))
>> + return;
>> +
>> + pmc_release_perf_event(pmc);
>> +
>> + pmc->current_config = new_config;
>> + pmc_reprogram_counter(pmc, PERF_TYPE_RAW,
>> + (eventsel & AMD64_RAW_EVENT_MASK),
>> + !(eventsel & ARCH_PERFMON_EVENTSEL_USR),
>> + !(eventsel & ARCH_PERFMON_EVENTSEL_OS),
>> + eventsel & ARCH_PERFMON_EVENTSEL_INT,
>> + (eventsel & HSW_IN_TX),
>> + (eventsel & HSW_IN_TX_CHECKPOINTED));
>
> It seems that this extremely long argument list was motivated by the
> differences between the two original call sites. Now that you have
> mocked up a full eventsel (with USR, OS, INT, IN_TX, and IN_TXCP bits)
> for the fixed counters, why not pass the entire eventsel as the third
I've thought about it.
I'm trying to pass-in generic bits (EVENT_MASK, USER, OS, INT) to
pmc_reprogram_counter() and let the latter handle the implementation details
of assembling the "struct perf_event_attr" to talk carefully with perf core.
I suppose the fixed counters doesn't support IN_TX* bits and I try to
clean those two away in another patch as you know.
In terms of code readability, the current one achieves a good balance.
> argument and drop all of the rest? Then, pmc_reprogram_counter() can
> extract/check the bits of interest.
>
>> }
>> EXPORT_SYMBOL_GPL(reprogram_counter);
>>
>> @@ -451,17 +426,6 @@ void kvm_pmu_init(struct kvm_vcpu *vcpu)
>> kvm_pmu_refresh(vcpu);
>> }
>>
>> -static inline bool pmc_speculative_in_use(struct kvm_pmc *pmc)
>> -{
>> - struct kvm_pmu *pmu = pmc_to_pmu(pmc);
>> -
>> - if (pmc_is_fixed(pmc))
>> - return fixed_ctrl_field(pmu->fixed_ctr_ctrl,
>> - pmc->idx - INTEL_PMC_IDX_FIXED) & 0x3;
>> -
>> - return pmc->eventsel & ARCH_PERFMON_EVENTSEL_ENABLE;
>> -}
>> -
>> /* Release perf_events for vPMCs that have been unused for a full time slice. */
>> void kvm_pmu_cleanup(struct kvm_vcpu *vcpu)
>> {
>> diff --git a/arch/x86/kvm/vmx/pmu_intel.c b/arch/x86/kvm/vmx/pmu_intel.c
>> index 19b78a9d9d47..d823fbe4e155 100644
>> --- a/arch/x86/kvm/vmx/pmu_intel.c
>> +++ b/arch/x86/kvm/vmx/pmu_intel.c
>> @@ -492,7 +492,7 @@ static void intel_pmu_refresh(struct kvm_vcpu *vcpu)
>> pmu->reserved_bits = 0xffffffff00200000ull;
>>
>> entry = kvm_find_cpuid_entry(vcpu, 0xa, 0);
>> - if (!entry || !vcpu->kvm->arch.enable_pmu)
>> + if (!entry || !vcpu->kvm->arch.enable_pmu || !boot_cpu_has(X86_FEATURE_ARCH_PERFMON))
>
> This change seems unrelated.
The intention of using the PERF_TYPE_HARDWARE type is to emulate guest architecture
PMU on a host without architecture PMU (the oldest Pentium 4), for which the
guest vPMC
needs to be reprogrammed using the kernel generic perf_hw_id.
This is the most original story of PERF_TYPE_HARDWARE, thanks to history teacher
Paolo,
who also suggested this way to drop this kind of support.
>
>> return;
>> eax.full = entry->eax;
>> edx.full = entry->edx;
>> --
>> 2.35.1
>>
next prev parent reply other threads:[~2022-03-08 11:44 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-03-02 11:13 [PATCH v2 00/12] KVM: x86/pmu: Get rid of PERF_TYPE_HARDWAR and other minor fixes Like Xu
2022-03-02 11:13 ` [PATCH v2 01/12] KVM: x86/pmu: Update comments for AMD gp counters Like Xu
2022-03-02 11:13 ` [PATCH v2 02/12] KVM: x86/pmu: Extract check_pmu_event_filter() from the same semantics Like Xu
2022-03-02 11:13 ` [PATCH v2 03/12] KVM: x86/pmu: Pass only "struct kvm_pmc *pmc" to reprogram_counter() Like Xu
2022-03-02 11:13 ` [PATCH v2 04/12] KVM: x86/pmu: Drop "u64 eventsel" for reprogram_gp_counter() Like Xu
2022-03-02 11:13 ` [PATCH v2 05/12] KVM: x86/pmu: Drop "u8 ctrl, int idx" for reprogram_fixed_counter() Like Xu
2022-03-02 11:13 ` [PATCH v2 06/12] KVM: x86/pmu: Use only the uniformly exported interface reprogram_counter() Like Xu
2022-03-02 11:13 ` [PATCH v2 07/12] KVM: x86/pmu: Use PERF_TYPE_RAW to merge reprogram_{gp, fixed}counter() Like Xu
2022-03-08 0:36 ` Jim Mattson
2022-03-08 11:43 ` Like Xu [this message]
2022-03-02 11:13 ` [PATCH v2 08/12] perf: x86/core: Add interface to query perfmon_event_map[] directly Like Xu
2022-03-02 11:13 ` [PATCH v2 09/12] KVM: x86/pmu: Replace pmc_perf_hw_id() with perf_get_hw_event_config() Like Xu
2022-03-02 11:13 ` [PATCH v2 10/12] KVM: x86/pmu: Drop amd_event_mapping[] in the KVM context Like Xu
2022-03-02 11:13 ` [PATCH v2 11/12] KVM: x86/pmu: Protect kvm->arch.pmu_event_filter with SRCU Like Xu
2022-03-02 11:13 ` [PATCH v2 12/12] KVM: x86/pmu: Clear reserved bit PERF_CTL2[43] for AMD erratum 1292 Like Xu
2022-03-02 17:52 ` Jim Mattson
2022-03-04 9:46 ` Like Xu
2022-03-04 19:06 ` Jim Mattson
2022-03-08 11:25 ` Like Xu
2022-03-08 16:14 ` Jim Mattson
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=888d5878-a2be-4624-d2c5-227fa19c8150@gmail.com \
--to=like.xu.linux@gmail.com \
--cc=jmattson@google.com \
--cc=joro@8bytes.org \
--cc=kvm@vger.kernel.org \
--cc=likexu@tencent.com \
--cc=linux-kernel@vger.kernel.org \
--cc=pbonzini@redhat.com \
--cc=peterz@infradead.org \
--cc=seanjc@google.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