From: Sean Christopherson <seanjc@google.com>
To: Like Xu <like.xu.linux@gmail.com>
Cc: Paolo Bonzini <pbonzini@redhat.com>,
Jim Mattson <jmattson@google.com>,
linux-kernel@vger.kernel.org, kvm@vger.kernel.org
Subject: Re: [PATCH RESEND v2 5/8] KVM: x86/pmu: Defer reprogram_counter() to kvm_pmu_handle_event()
Date: Tue, 30 Aug 2022 17:50:49 +0000 [thread overview]
Message-ID: <Yw5N+eGfOsCgtHpw@google.com> (raw)
In-Reply-To: <20220823093221.38075-6-likexu@tencent.com>
On Tue, Aug 23, 2022, Like Xu wrote:
> From: Like Xu <likexu@tencent.com>
>
> During a KVM-trap from vm-exit to vm-entry, requests from different
> sources will try to create one or more perf_events via reprogram_counter(),
> which will allow some predecessor actions to be undone posteriorly,
> especially repeated calls to some perf subsystem interfaces. These
> repetitive calls can be omitted because only the final state of the
> perf_event and the hardware resources it occupies will take effect
> for the guest right before the vm-entry.
>
> To realize this optimization, KVM marks the creation requirements via
> an inline version of reprogram_counter(), and then defers the actual
> execution with the help of vcpu KVM_REQ_PMU request.
Use imperative mood and state what change is being made, not what KVM's behavior
is as a result of the change.
And this is way more complicated than it needs to be, and it also neglects to
call out that the deferred logic is needed for a bug fix. IIUC:
Batch reprogramming PMU counters by setting KVM_REQ_PMU and thus deferring
reprogramming kvm_pmu_handle_event() to avoid reprogramming a counter
multiple times during a single VM-Exit.
Deferring programming will also allow KVM to fix a bug where immediately
reprogramming a counter can result in sleeping (taking a mutex) while
interrupts are disabled in the VM-Exit fastpath.
> Opportunistically update related comments to avoid misunderstandings.
>
> diff --git a/arch/x86/kvm/pmu.c b/arch/x86/kvm/pmu.c
> index d9b9a0f0db17..6940cbeee54d 100644
> --- a/arch/x86/kvm/pmu.c
> +++ b/arch/x86/kvm/pmu.c
> @@ -101,7 +101,7 @@ static inline void __kvm_perf_overflow(struct kvm_pmc *pmc, bool in_pmi)
> struct kvm_pmu *pmu = pmc_to_pmu(pmc);
> bool skip_pmi = false;
>
> - /* Ignore counters that have been reprogrammed already. */
> + /* Ignore counters that have not been reprogrammed. */
Eh, just drop this comment, it's fairly obvious what the code is doing and your
suggested comment is wrong in the sense that the counters haven't actually been
reprogrammed, i.e. it should be:
/* Ignore counters that don't need to be reprogrammed. */
but IMO that's pretty obvious.
> if (test_and_set_bit(pmc->idx, pmu->reprogram_pmi))
> return;
>
> @@ -293,7 +293,7 @@ static bool check_pmu_event_filter(struct kvm_pmc *pmc)
> return allow_event;
> }
>
> -void reprogram_counter(struct kvm_pmc *pmc)
> +static void __reprogram_counter(struct kvm_pmc *pmc)
This is misleading. Double-underscore variants are usually inner helpers, whereas
these have a different relationship.
Instaed of renaming reprogram_counter(), how about introcuing
kvm_pmu_request_counter_reprogam()
to make it obvious that KVM is _requesting_ a reprogram and not actually doing
the reprogram.
next prev parent reply other threads:[~2022-08-30 17:54 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-08-23 9:32 [PATCH RESEND v2 0/8] x86/pmu: Corner cases fixes and optimization Like Xu
2022-08-23 9:32 ` [PATCH RESEND v2 1/8] perf/x86/core: Completely disable guest PEBS via guest's global_ctrl Like Xu
2022-08-30 17:40 ` Sean Christopherson
2022-08-23 9:32 ` [PATCH RESEND v2 2/8] KVM: x86/pmu: Avoid setting BIT_ULL(-1) to pmu->host_cross_mapped_mask Like Xu
2022-08-23 9:32 ` [PATCH RESEND v2 3/8] KVM: x86/pmu: Don't generate PEBS records for emulated instructions Like Xu
2022-08-23 9:32 ` [PATCH RESEND v2 4/8] KVM: x86/pmu: Avoid using PEBS perf_events for normal counters Like Xu
2022-08-23 9:32 ` [PATCH RESEND v2 5/8] KVM: x86/pmu: Defer reprogram_counter() to kvm_pmu_handle_event() Like Xu
2022-08-30 17:50 ` Sean Christopherson [this message]
2022-08-23 9:32 ` [PATCH RESEND v2 6/8] KVM: x86/pmu: Defer counter emulated overflow via pmc->stale_counter Like Xu
2022-08-30 17:59 ` Sean Christopherson
2022-08-23 9:32 ` [PATCH RESEND v2 7/8] KVM: x86/svm/pmu: Direct access pmu->gp_counter[] to implement amd_*_to_pmc() Like Xu
2022-08-30 18:07 ` Sean Christopherson
2022-08-23 9:32 ` [PATCH RESEND v2 8/8] KVM: x86/svm/pmu: Rewrite get_gp_pmc_amd() for more counters scalability Like Xu
2022-08-30 18:24 ` Sean Christopherson
2022-08-30 17:29 ` [PATCH RESEND v2 0/8] x86/pmu: Corner cases fixes and optimization Sean Christopherson
2022-08-31 8:05 ` Like Xu
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=Yw5N+eGfOsCgtHpw@google.com \
--to=seanjc@google.com \
--cc=jmattson@google.com \
--cc=kvm@vger.kernel.org \
--cc=like.xu.linux@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--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