public inbox for linux-perf-users@vger.kernel.org
 help / color / mirror / Atom feed
From: "Yosry Ahmed" <yosry.ahmed@linux.dev>
To: "Jim Mattson" <jmattson@google.com>
Cc: "Peter Zijlstra" <peterz@infradead.org>,
	"Ingo Molnar" <mingo@redhat.com>,
	"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>,
	"Thomas Gleixner" <tglx@kernel.org>,
	"Borislav Petkov" <bp@alien8.de>,
	"Dave Hansen" <dave.hansen@linux.intel.com>,
	x86@kernel.org, "H. Peter Anvin" <hpa@zytor.com>,
	"Sean Christopherson" <seanjc@google.com>,
	"Paolo Bonzini" <pbonzini@redhat.com>,
	"Shuah Khan" <shuah@kernel.org>,
	linux-perf-users@vger.kernel.org, linux-kernel@vger.kernel.org,
	kvm@vger.kernel.org, linux-kselftest@vger.kernel.org,
	mizhang@google.com, sandipan.das@amd.com
Subject: Re: [PATCH v2 3/5] KVM: x86/pmu: Refresh Host-Only/Guest-Only eventsel at nested transitions
Date: Fri, 30 Jan 2026 23:40:57 +0000	[thread overview]
Message-ID: <626dbe6541266f61e8b505202cf49c94c4fee12e@linux.dev> (raw)
In-Reply-To: <CALMp9eS7Za_vFdh8YBzycV2g87gZ9uj_S1MOYrgJ1+ShwVVWZw@mail.gmail.com>

January 30, 2026 at 3:30 PM, "Jim Mattson" <jmattson@google.com> wrote:


> 
> On Fri, Jan 30, 2026 at 7:26 AM Yosry Ahmed <yosry.ahmed@linux.dev> wrote:
> 
> > 
> > On Thu, Jan 29, 2026 at 03:28:08PM -0800, Jim Mattson wrote:
> >  Add amd_pmu_refresh_host_guest_eventsel_hw() to recalculate eventsel_hw for
> >  all PMCs based on the current vCPU state. This is needed because Host-Only
> >  and Guest-Only counters must be enabled/disabled at:
> > 
> >  - SVME changes: When EFER.SVME is modified, counters with Guest-Only bits
> >  need their hardware enable state updated.
> > 
> >  - Nested transitions: When entering or leaving guest mode, Host-Only
> >  counters should be disabled/enabled and Guest-Only counters should be
> >  enabled/disabled accordingly.
> > 
> >  Introduce svm_enter_guest_mode() and svm_leave_guest_mode() wrappers that
> >  call enter_guest_mode()/leave_guest_mode() followed by the PMU refresh,
> >  ensuring the PMU state stays synchronized with guest mode transitions.
> > 
> >  Signed-off-by: Jim Mattson <jmattson@google.com>
> >  ---
> >  arch/x86/kvm/svm/nested.c | 6 +++---
> >  arch/x86/kvm/svm/pmu.c | 12 ++++++++++++
> >  arch/x86/kvm/svm/svm.c | 2 ++
> >  arch/x86/kvm/svm/svm.h | 17 +++++++++++++++++
> >  4 files changed, 34 insertions(+), 3 deletions(-)
> > 
> >  diff --git a/arch/x86/kvm/svm/nested.c b/arch/x86/kvm/svm/nested.c
> >  index de90b104a0dd..a7d1901f256b 100644
> >  --- a/arch/x86/kvm/svm/nested.c
> >  +++ b/arch/x86/kvm/svm/nested.c
> >  @@ -757,7 +757,7 @@ static void nested_vmcb02_prepare_control(struct vcpu_svm *svm,
> >  nested_svm_transition_tlb_flush(vcpu);
> > 
> >  /* Enter Guest-Mode */
> >  - enter_guest_mode(vcpu);
> >  + svm_enter_guest_mode(vcpu);
> > 
> >  FWIW, I think this name is a bit confusing because we also have
> >  enter_svm_guest_mode(). So we end up with:
> > 
> >  enter_svm_guest_mode() -> nested_vmcb02_prepare_control() ->
> >  svm_enter_guest_mode() -> enter_guest_mode()
> > 
> >  I actually have another proposed change [1] that moves
> >  enter_guest_mode() directly into enter_svm_guest_mode(), so the sequence
> >  would end up being:
> > 
> >  enter_svm_guest_mode() -> svm_enter_guest_mode() -> enter_guest_mode()
> > 
> Yes, that is confusing. What if I renamed the existing function to
> something like svm_nested_switch_to_vmcb02()?
> 
> Alternatively, I could go back to introducing a new PMU_OP, call it
> from {enter,leave}_guest_mode(), and drop the wrappers.

We could just call amd_pmu_refresh_host_guest_eventsel_hw() every time we call enter_guest_mode() and leave_guest_mode(), which is more error-prone but there's already other things in that category.

We could also call it from svm_switch_vmcb(), which will add some calls to extra places but I assume that would be fine?

I personally prefer the former tbh, as it's otherwise easy to miss.

> 
> > 
> > [1] https://lore.kernel.org/kvm/20260115011312.3675857-9-yosry.ahmed@linux.dev/
> >
>

  reply	other threads:[~2026-01-30 23:41 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-01-29 23:28 [PATCH v2 0/5] KVM: x86/pmu: Add support for AMD Host-Only/Guest-Only bits Jim Mattson
2026-01-29 23:28 ` [PATCH v2 1/5] KVM: x86/pmu: Introduce amd_pmu_set_eventsel_hw() Jim Mattson
2026-01-29 23:28 ` [PATCH v2 2/5] KVM: x86/pmu: Disable Host-Only/Guest-Only events as appropriate for vCPU state Jim Mattson
2026-01-29 23:28 ` [PATCH v2 3/5] KVM: x86/pmu: Refresh Host-Only/Guest-Only eventsel at nested transitions Jim Mattson
2026-01-30 15:26   ` Yosry Ahmed
2026-01-30 23:30     ` Jim Mattson
2026-01-30 23:40       ` Yosry Ahmed [this message]
2026-02-03 20:46         ` Jim Mattson
2026-01-29 23:28 ` [PATCH v2 4/5] KVM: x86/pmu: Allow Host-Only/Guest-Only bits with nSVM and mediated PMU Jim Mattson
2026-01-29 23:28 ` [PATCH v2 5/5] KVM: selftests: x86: Add svm_pmu_host_guest_test for Host-Only/Guest-Only bits 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=626dbe6541266f61e8b505202cf49c94c4fee12e@linux.dev \
    --to=yosry.ahmed@linux.dev \
    --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=mizhang@google.com \
    --cc=namhyung@kernel.org \
    --cc=pbonzini@redhat.com \
    --cc=peterz@infradead.org \
    --cc=sandipan.das@amd.com \
    --cc=seanjc@google.com \
    --cc=shuah@kernel.org \
    --cc=tglx@kernel.org \
    --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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox