public inbox for kvm@vger.kernel.org
 help / color / mirror / Atom feed
From: Sean Christopherson <seanjc@google.com>
To: Yosry Ahmed <yosry@kernel.org>
Cc: Paolo Bonzini <pbonzini@redhat.com>,
	Jim Mattson <jmattson@google.com>,
	kvm@vger.kernel.org,  linux-kernel@vger.kernel.org
Subject: Re: [PATCH v4 4/6] KVM: x86/pmu: Re-evaluate Host-Only/Guest-Only on nested SVM transitions
Date: Mon, 6 Apr 2026 18:35:51 -0700	[thread overview]
Message-ID: <adRfdw5jpvibQkOq@google.com> (raw)
In-Reply-To: <20260326031150.3774017-5-yosry@kernel.org>

On Thu, Mar 26, 2026, Yosry Ahmed wrote:
> Reprogram all counters on nested transitions for the mediated PMU, to
> re-evaluate Host-Only and Guest-Only bits and enable/disable the PMU
> counters accordingly. For example, if Host-Only is set and Guest-Only is
> cleared, a counter should be disabled when entering guest mode and
> enabled when exiting guest mode.
> 
> Having one of Host-Only and Guest-Only set is only effective when
> EFER.SVME is set, so also trigger counter reprogramming when EFER.SVME
> is toggled.
> 
> Track counters with one of Host-Only and Guest-Only set as counters
> requiring reprogramming on nested transitions in a bitmap. Use the
> bitmap to only request KVM_PMU_REQ if some counters need reprogramming,
> and only reprogram the counters that actually need it.
> 
> Track such counters even if EFER.SVME is cleared, such that if/when
> EFER.SVME is set, KVM can reprogram those counters and enable/disable
> them appropriately. Otherwise, toggling EFER.SVME would need to
> reprogram all counters and use a different code path than
> kvm_pmu_handle_nested_transition().
> 
> Signed-off-by: Yosry Ahmed <yosry@kernel.org>
> ---
>  arch/x86/include/asm/kvm_host.h |  6 ++++++
>  arch/x86/kvm/pmu.c              |  1 +
>  arch/x86/kvm/pmu.h              | 13 +++++++++++++
>  arch/x86/kvm/svm/pmu.c          | 13 ++++++++++++-
>  arch/x86/kvm/svm/svm.c          |  1 +
>  arch/x86/kvm/x86.h              |  5 +++++
>  6 files changed, 38 insertions(+), 1 deletion(-)
> 
> diff --git a/arch/x86/include/asm/kvm_host.h b/arch/x86/include/asm/kvm_host.h
> index d3bdc98281339..b2f8710838372 100644
> --- a/arch/x86/include/asm/kvm_host.h
> +++ b/arch/x86/include/asm/kvm_host.h
> @@ -594,6 +594,12 @@ struct kvm_pmu {
>  	DECLARE_BITMAP(pmc_counting_instructions, X86_PMC_IDX_MAX);
>  	DECLARE_BITMAP(pmc_counting_branches, X86_PMC_IDX_MAX);
>  
> +	/*
> +	 * Whether or not PMU counters need to be reprogrammed on transitions
> +	 * between L1 and L2 (or when nesting enablement is toggled).
> +	 */
> +	DECLARE_BITMAP(pmc_needs_nested_reprogram, X86_PMC_IDX_MAX);

Hmm, I think this should be reprogram_pmc_on_nested_transition, or something like
that.  I don't like using "needs" because KVM tends to use "needs" for one-shot
things, e.g. "xyz needs to be sync'd on the next whatever".  And while the code
kinda-sorta takes that approach, in practice it doesn't; clearing the bits and
then setting them again is really just an implementation quirk to keep things
simple.

Conceptually, these flags are much "stickier" in that they are kept set across
all nested transitions, and only cleared when the event selector itself is
changed in some way.

> diff --git a/arch/x86/kvm/pmu.h b/arch/x86/kvm/pmu.h
> index bdbe0456049d0..fb73806d3bfa0 100644
> --- a/arch/x86/kvm/pmu.h
> +++ b/arch/x86/kvm/pmu.h
> @@ -248,6 +248,19 @@ static inline bool kvm_pmu_is_fastpath_emulation_allowed(struct kvm_vcpu *vcpu)
>  				  X86_PMC_IDX_MAX);
>  }
>  
> +static inline void kvm_pmu_handle_nested_transition(struct kvm_vcpu *vcpu)
> +{
> +	struct kvm_pmu *pmu = vcpu_to_pmu(vcpu);
> +
> +	if (bitmap_empty(pmu->pmc_needs_nested_reprogram, X86_PMC_IDX_MAX))
> +		return;
> +
> +	BUILD_BUG_ON(sizeof(pmu->pmc_needs_nested_reprogram) != sizeof(atomic64_t));
> +	atomic64_or(*(s64 *)pmu->pmc_needs_nested_reprogram,
> +		    &vcpu_to_pmu(vcpu)->__reprogram_pmi);

And here especially I think reprogram_pmc_on_nested_transition works better,
e.g. it's a bit more obvious that leaving reprogram_pmc_on_nested_transition
as-is is intentional.

> +	kvm_make_request(KVM_REQ_PMU, vcpu);

  reply	other threads:[~2026-04-07  1:35 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-03-26  3:11 [PATCH v4 0/6] KVM: x86/pmu: Add support for AMD Host-Only/Guest-Only bits Yosry Ahmed
2026-03-26  3:11 ` [PATCH v4 1/6] KVM: x86: Move enable_pmu/enable_mediated_pmu to pmu.h and pmu.c Yosry Ahmed
2026-03-26  3:11 ` [PATCH v4 2/6] KVM: x86: Move guest_mode helpers to x86.h Yosry Ahmed
2026-03-26 22:48   ` kernel test robot
2026-03-26 23:18     ` Yosry Ahmed
2026-03-27  3:15   ` kernel test robot
2026-03-26  3:11 ` [PATCH v4 3/6] KVM: x86/pmu: Disable counters based on Host-Only/Guest-Only bits in SVM Yosry Ahmed
2026-04-07  1:30   ` Sean Christopherson
2026-03-26  3:11 ` [PATCH v4 4/6] KVM: x86/pmu: Re-evaluate Host-Only/Guest-Only on nested SVM transitions Yosry Ahmed
2026-04-07  1:35   ` Sean Christopherson [this message]
2026-03-26  3:11 ` [PATCH v4 5/6] KVM: x86/pmu: Allow Host-Only/Guest-Only bits with nSVM and mediated PMU Yosry Ahmed
2026-03-26  3:11 ` [PATCH v4 6/6] KVM: selftests: Add svm_pmu_host_guest_test for Host-Only/Guest-Only bits Yosry Ahmed
2026-04-07  1:39   ` Sean Christopherson
2026-04-07  3:23     ` 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=adRfdw5jpvibQkOq@google.com \
    --to=seanjc@google.com \
    --cc=jmattson@google.com \
    --cc=kvm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=pbonzini@redhat.com \
    --cc=yosry@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox