[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <Zhhvcd1R_uz_xbRU@google.com>
Date: Thu, 11 Apr 2024 16:17:05 -0700
From: Sean Christopherson <seanjc@...gle.com>
To: Xiong Zhang <xiong.y.zhang@...ux.intel.com>
Cc: pbonzini@...hat.com, peterz@...radead.org, mizhang@...gle.com,
kan.liang@...el.com, zhenyuw@...ux.intel.com, dapeng1.mi@...ux.intel.com,
jmattson@...gle.com, kvm@...r.kernel.org, linux-perf-users@...r.kernel.org,
linux-kernel@...r.kernel.org, zhiyuan.lv@...el.com, eranian@...gle.com,
irogers@...gle.com, samantha.alt@...el.com, like.xu.linux@...il.com,
chao.gao@...el.com
Subject: Re: [RFC PATCH 39/41] KVM: x86/pmu: Implement emulated counter
increment for passthrough PMU
On Thu, Apr 11, 2024, Sean Christopherson wrote:
> > + struct kvm_pmu *pmu = vcpu_to_pmu(vcpu);
> > + int bit;
> > +
> > + for_each_set_bit(bit, pmu->incremented_pmc_idx, X86_PMC_IDX_MAX) {
>
> I don't love the "incremented_pmc_idx" name. It's specifically for emulated
> events, that should ideally be clear in the name.
>
> And does the tracking the emulated counters actually buy anything? Iterating
> over all PMCs and checking emulated_counter doesn't seem like it'd be measurably
> slow, especially not when this path is likely writing multiple MSRs.
>
> Wait, why use that and not reprogram_pmi?
If the name is a sticking point, just rename it to something generic, e.g.
dirty_pmcs or something.
Powered by blists - more mailing lists