From: Sean Christopherson <seanjc@google.com>
To: Jim Mattson <jmattson@google.com>
Cc: Paolo Bonzini <pbonzini@redhat.com>,
Thomas Gleixner <tglx@linutronix.de>,
Ingo Molnar <mingo@redhat.com>, Borislav Petkov <bp@alien8.de>,
Dave Hansen <dave.hansen@linux.intel.com>,
x86@kernel.org, "H. Peter Anvin" <hpa@zytor.com>,
Peter Zijlstra <peterz@infradead.org>,
Arnaldo Carvalho de Melo <acme@kernel.org>,
Namhyung Kim <namhyung@kernel.org>,
Mark Rutland <mark.rutland@arm.com>,
Alexander Shishkin <alexander.shishkin@linux.intel.com>,
Jiri Olsa <jolsa@kernel.org>, Ian Rogers <irogers@google.com>,
Adrian Hunter <adrian.hunter@intel.com>,
James Clark <james.clark@linaro.org>,
Shuah Khan <shuah@kernel.org>,
kvm@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-perf-users@vger.kernel.org,
linux-kselftest@vger.kernel.org
Subject: Re: [PATCH 2/6] KVM: x86/pmu: Disable HG_ONLY events as appropriate for current vCPU state
Date: Thu, 22 Jan 2026 08:33:30 -0800 [thread overview]
Message-ID: <aXJRWtdzjcb8_APA@google.com> (raw)
In-Reply-To: <20260121225438.3908422-3-jmattson@google.com>
On Wed, Jan 21, 2026, Jim Mattson wrote:
> Introduce amd_pmu_dormant_hg_event(), which determines whether an AMD PMC
> should be dormant (i.e. not count) based on the guest's Host-Only and
> Guest-Only event selector bits and the current vCPU state.
>
> Update amd_pmu_set_eventsel_hw() to clear the event selector's enable bit
> when the event is dormant.
>
> Signed-off-by: Jim Mattson <jmattson@google.com>
> ---
> arch/x86/include/asm/perf_event.h | 2 ++
> arch/x86/kvm/svm/pmu.c | 23 +++++++++++++++++++++++
> 2 files changed, 25 insertions(+)
>
> diff --git a/arch/x86/include/asm/perf_event.h b/arch/x86/include/asm/perf_event.h
> index 0d9af4135e0a..7649d79d91a6 100644
> --- a/arch/x86/include/asm/perf_event.h
> +++ b/arch/x86/include/asm/perf_event.h
> @@ -58,6 +58,8 @@
> #define AMD64_EVENTSEL_INT_CORE_ENABLE (1ULL << 36)
> #define AMD64_EVENTSEL_GUESTONLY (1ULL << 40)
> #define AMD64_EVENTSEL_HOSTONLY (1ULL << 41)
> +#define AMD64_EVENTSEL_HG_ONLY \
I would strongly prefer to avoid the HG acronym, as it's not immediately obvious
that it's HOST_GUEST, and avoiding long lines even with the full HOST_GUEST is
pretty easy.
The name should also have "MASK" at the end to make it more obvious this is a
multi-flag macro, i.e. not a single-flag value. Otherwise the intent and thus
correctness of code like this isn't obvious:
if (eventsel & AMD64_EVENTSEL_HG_ONLY)
How about AMD64_EVENTSEL_HOST_GUEST_MASK?
> + (AMD64_EVENTSEL_HOSTONLY | AMD64_EVENTSEL_GUESTONLY)
>
> #define AMD64_EVENTSEL_INT_CORE_SEL_SHIFT 37
> #define AMD64_EVENTSEL_INT_CORE_SEL_MASK \
> diff --git a/arch/x86/kvm/svm/pmu.c b/arch/x86/kvm/svm/pmu.c
> index 33c139b23a9e..f619417557f9 100644
> --- a/arch/x86/kvm/svm/pmu.c
> +++ b/arch/x86/kvm/svm/pmu.c
> @@ -147,10 +147,33 @@ static int amd_pmu_get_msr(struct kvm_vcpu *vcpu, struct msr_data *msr_info)
> return 1;
> }
>
> +static bool amd_pmu_dormant_hg_event(struct kvm_pmc *pmc)
I think I would prefer to flip the polarity, even though the only caller would
then need to invert the return value. Partly because I think we can come up with
a more intuitive name, partly because it'll make the last check in particular
more intutive, i.e. IMO, checking "guest == guest"
return !!(hg_only & AMD64_EVENTSEL_GUESTONLY) == is_guest_mode(vcpu);
is more obvious than checking "host == guest":
return !!(hg_only & AMD64_EVENTSEL_GUESTONLY) == is_guest_mode(vcpu);
Maybe amd_pmc_is_active() or amd_pmc_counts_in_current_mode()?
> +{
> + u64 hg_only = pmc->eventsel & AMD64_EVENTSEL_HG_ONLY;
> + struct kvm_vcpu *vcpu = pmc->vcpu;
> +
> + if (hg_only == 0)
!hg_only
In the spirit of avoiding the "hg" acronym, what if we do something like this?
const u64 HOST_GUEST_MASK = AMD64_EVENTSEL_HOST_GUEST_MASK;
struct kvm_vcpu *vcpu = pmc->vcpu;
u64 eventsel = pmc->eventsel;
/*
* PMCs count in both host and guest if neither {HOST,GUEST}_ONLY flags
* are set, or if both flags are set.
*/
if (!(eventsel & HOST_GUEST_MASK) ||
((eventsel & HOST_GUEST_MASK) == HOST_GUEST_MASK))
return true;
/* {HOST,GUEST}_ONLY bits are ignored when SVME is clear. */
if (!(vcpu->arch.efer & EFER_SVME))
return true;
return !!(eventsel & AMD64_EVENTSEL_GUESTONLY) == is_guest_mode(vcpu);
> + /* Not an HG_ONLY event */
Please don't put comments inside single-line if-statements. 99% of the time
it's easy to put the comment outside of the if-statement, and doing so encourages
a more verbose comment and avoids a "does this if-statement need curly-braces"
debate.
> + return false;
> +
> + if (!(vcpu->arch.efer & EFER_SVME))
> + /* HG_ONLY bits are ignored when SVME is clear */
> + return false;
> +
> + /* Always active if both HG_ONLY bits are set */
> + if (hg_only == AMD64_EVENTSEL_HG_ONLY)
I vote to check this condition at the same time !hg_only is checked. From a
*very* pedantic perspective, one could argue it's "wrong" to check the bits when
SVME=0, but the purpose of the helper is to detect if the PMC is active or not.
Precisely following the architectural behavior is unnecessary.
> + return false;
> +
> + return !!(hg_only & AMD64_EVENTSEL_HOSTONLY) == is_guest_mode(vcpu);
> +}
> +
> static void amd_pmu_set_eventsel_hw(struct kvm_pmc *pmc)
> {
> pmc->eventsel_hw = (pmc->eventsel & ~AMD64_EVENTSEL_HOSTONLY) |
> AMD64_EVENTSEL_GUESTONLY;
> +
> + if (amd_pmu_dormant_hg_event(pmc))
> + pmc->eventsel_hw &= ~ARCH_PERFMON_EVENTSEL_ENABLE;
> }
>
> static int amd_pmu_set_msr(struct kvm_vcpu *vcpu, struct msr_data *msr_info)
> --
> 2.52.0.457.g6b5491de43-goog
>
next prev parent reply other threads:[~2026-01-22 16:33 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-01-21 22:53 [PATCH 0/6] KVM: x86/pmu: Add support for AMD HG_ONLY bits Jim Mattson
2026-01-21 22:53 ` [PATCH 1/6] KVM: x86/pmu: Introduce amd_pmu_set_eventsel_hw() Jim Mattson
2026-01-22 16:04 ` Sean Christopherson
2026-01-22 21:57 ` Jim Mattson
2026-01-21 22:54 ` [PATCH 2/6] KVM: x86/pmu: Disable HG_ONLY events as appropriate for current vCPU state Jim Mattson
2026-01-22 16:33 ` Sean Christopherson [this message]
2026-01-22 22:47 ` Jim Mattson
2026-01-22 23:51 ` Sean Christopherson
2026-01-21 22:54 ` [PATCH 3/6] KVM: x86/pmu: Track enabled AMD PMCs with Host-Only xor Guest-Only bits set Jim Mattson
2026-01-22 16:49 ` Sean Christopherson
2026-01-24 1:09 ` Jim Mattson
2026-01-21 22:54 ` [PATCH 4/6] KVM: x86/pmu: [De]activate HG_ONLY PMCs at SVME changes and nested transitions Jim Mattson
2026-01-22 16:55 ` Sean Christopherson
2026-01-28 23:43 ` Jim Mattson
2026-01-29 22:34 ` Sean Christopherson
2026-01-21 22:54 ` [PATCH 5/6] KVM: x86/pmu: Allow HG_ONLY bits with nSVM and mediated PMU Jim Mattson
2026-01-22 16:56 ` Sean Christopherson
2026-01-21 22:54 ` [PATCH 6/6] KVM: selftests: x86: Add svm_pmu_hg_test for HG_ONLY bits Jim Mattson
2026-01-22 17:12 ` Sean Christopherson
2026-01-28 23:47 ` Jim Mattson
2026-01-22 18:56 ` kernel test robot
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=aXJRWtdzjcb8_APA@google.com \
--to=seanjc@google.com \
--cc=acme@kernel.org \
--cc=adrian.hunter@intel.com \
--cc=alexander.shishkin@linux.intel.com \
--cc=bp@alien8.de \
--cc=dave.hansen@linux.intel.com \
--cc=hpa@zytor.com \
--cc=irogers@google.com \
--cc=james.clark@linaro.org \
--cc=jmattson@google.com \
--cc=jolsa@kernel.org \
--cc=kvm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-kselftest@vger.kernel.org \
--cc=linux-perf-users@vger.kernel.org \
--cc=mark.rutland@arm.com \
--cc=mingo@redhat.com \
--cc=namhyung@kernel.org \
--cc=pbonzini@redhat.com \
--cc=peterz@infradead.org \
--cc=shuah@kernel.org \
--cc=tglx@linutronix.de \
--cc=x86@kernel.org \
/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.