linux-kernel - Re: [PATCH v4 20/38] KVM: x86/pmu: Check if mediated vPMU can intercept rdpmc

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <aG6QeTXrd7Can8PK@google.com>
Date: Wed, 9 Jul 2025 08:53:29 -0700
From: Sean Christopherson <seanjc@...gle.com>
To: Sandipan Das <sandipan.das@....com>
Cc: Mingwei Zhang <mizhang@...gle.com>, Peter Zijlstra <peterz@...radead.org>, 
	Ingo Molnar <mingo@...hat.com>, Arnaldo Carvalho de Melo <acme@...nel.org>, Namhyung Kim <namhyung@...nel.org>, 
	Paolo Bonzini <pbonzini@...hat.com>, Mark Rutland <mark.rutland@....com>, 
	Alexander Shishkin <alexander.shishkin@...ux.intel.com>, Jiri Olsa <jolsa@...nel.org>, 
	Ian Rogers <irogers@...gle.com>, Adrian Hunter <adrian.hunter@...el.com>, Liang@...gle.com, 
	Kan <kan.liang@...ux.intel.com>, "H. Peter Anvin" <hpa@...or.com>, 
	linux-perf-users@...r.kernel.org, linux-kernel@...r.kernel.org, 
	kvm@...r.kernel.org, linux-kselftest@...r.kernel.org, 
	Yongwei Ma <yongwei.ma@...el.com>, Xiong Zhang <xiong.y.zhang@...ux.intel.com>, 
	Dapeng Mi <dapeng1.mi@...ux.intel.com>, Jim Mattson <jmattson@...gle.com>, 
	Zide Chen <zide.chen@...el.com>, Eranian Stephane <eranian@...gle.com>, 
	Shukla Manali <Manali.Shukla@....com>, Nikunj Dadhania <nikunj.dadhania@....com>
Subject: Re: [PATCH v4 20/38] KVM: x86/pmu: Check if mediated vPMU can
 intercept rdpmc

On Mon, May 26, 2025, Sandipan Das wrote:
> > @@ -212,6 +212,18 @@ static void amd_pmu_refresh(struct kvm_vcpu *vcpu)
> >  	bitmap_set(pmu->all_valid_pmc_idx, 0, pmu->nr_arch_gp_counters);
> >  }
> >  
> > +static void amd_pmu_refresh(struct kvm_vcpu *vcpu)
> > +{
> > +	struct vcpu_svm *svm = to_svm(vcpu);
> > +
> > +	__amd_pmu_refresh(vcpu);
> > +
> > +	if (kvm_rdpmc_in_guest(vcpu))
> > +		svm_clr_intercept(svm, INTERCEPT_RDPMC);
> > +	else
> > +		svm_set_intercept(svm, INTERCEPT_RDPMC);
> > +}
> > +
> 
> After putting kprobes on kvm_pmu_rdpmc(), I noticed that RDPMC instructions were
> getting intercepted for the secondary vCPUs. This happens because when secondary
> vCPUs come up, kvm_vcpu_reset() gets called after guest CPUID has been updated.
> While RDPMC interception is initially disabled in the kvm_pmu_refresh() path, it
> gets re-enabled in the kvm_vcpu_reset() path as svm_vcpu_reset() calls init_vmcb().
> We should consider adding the following change to avoid that.

Revisiting this code after the MSR interception rework, I think we should go for
a more complete, big-hammer solution.  Rather than manipulate intercepts during
kvm_pmu_refresh(), do the updates as part of the "common" recalc intercepts flow.
And then to trigger recalc on PERF_CAPABILITIES writes, turn KVM_REQ_MSR_FILTER_CHANGED
into a generic KVM_REQ_RECALC_INTERCEPTS.

That way there's one path for calculating dynamic intercepts, which should make it
much more difficult for us to screw up things like reacting to MSR filter changes.
And providing a single path avoids needing to have a series of back-and-forth calls
between common x86 code, PMU code, and vendor code.