[PATCH v2 0/3] powerpc/perf: Fix vpa-pmu driver to report correct numbers

[PATCH v2 0/3] powerpc/perf: Fix vpa-pmu driver to report correct numbers

[Gautam Menghani]

The vpa-pmu driver can sometimes report incorrect context switch latency
numbers:

$ perf stat -e vpa_pmu/l1_to_l2_lat/  --tid=2061  -I 1000
           time             counts unit events
     1.001022517 18,446,744,073,708,177,408      vpa_pmu/l1_to_l2_lat/
     2.002120674            345,092      vpa_pmu/l1_to_l2_lat/
     3.003171582            406,342      vpa_pmu/l1_to_l2_lat/
     4.004234838            340,836      vpa_pmu/l1_to_l2_lat/

These invalid numbers are observed because the vpa-pmu driver does not
handle the following scenarios:

1. The vCPU process gets rescheduled to a different host cpu.

2. The vCPU process is not running, and vpa_pmu_read() is called to read
counter values.

Fix the above cases by maintaining aggregate counter values inside the
vcpu->arch struct and using them to report data.


changes in v2:
1. Fix the output for "perf stat --cpu ..."
2. Add stable and fixes tags

Gautam Menghani (3):
  KVM: PPC: Book3S HV: Maintain aggregate context switch values for
    vCPUs
  powerpc/perf: Use the aggregate context switch values from vcpu struct
  powerpc/perf: Update prev_count of event to get accurate values

 arch/powerpc/include/asm/kvm_book3s_64.h |  3 --
 arch/powerpc/kvm/book3s_hv.c             | 51 ++----------------------
 arch/powerpc/perf/vpa-pmu.c              | 25 +++++++++---
 3 files changed, 22 insertions(+), 57 deletions(-)

-- 
2.54.0

[PATCH v2 1/3] KVM: PPC: Book3S HV: Maintain aggregate context switch values for vCPUs

[Gautam Menghani]

The variables in vcpu->arch currently store the latest values read from
PACA when the vCPU exits. Change this to instead store aggregate values
so that every vCPU has its own record of total context switch latencies
it has accumulated. This is essential for the vpa-pmu driver to report
correct numbers.

Fixes: 176cda0619b6 ("powerpc/perf: Add perf interface to expose vpa counters")
Cc: <stable@vger.kernel.org>
Signed-off-by: Gautam Menghani <gautam@linux.ibm.com>
---
v1 -> v2:
1. Add stable/fixes tags

 arch/powerpc/kvm/book3s_hv.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/arch/powerpc/kvm/book3s_hv.c b/arch/powerpc/kvm/book3s_hv.c
index 61dbeea317f3..342168b8bfc8 100644
--- a/arch/powerpc/kvm/book3s_hv.c
+++ b/arch/powerpc/kvm/book3s_hv.c
@@ -4163,12 +4163,12 @@ static void do_trace_nested_cs_time(struct kvm_vcpu *vcpu)
 	trace_kvmppc_vcpu_stats(vcpu, l1_to_l2_ns - *l1_to_l2_cs_ptr,
 					l2_to_l1_ns - *l2_to_l1_cs_ptr,
 					l2_runtime_ns - *l2_runtime_agg_ptr);
+	vcpu->arch.l1_to_l2_cs += (l1_to_l2_ns - *l1_to_l2_cs_ptr);
+	vcpu->arch.l2_to_l1_cs += (l2_to_l1_ns - *l2_to_l1_cs_ptr);
+	vcpu->arch.l2_runtime_agg += (l2_runtime_ns - *l2_runtime_agg_ptr);
 	*l1_to_l2_cs_ptr = l1_to_l2_ns;
 	*l2_to_l1_cs_ptr = l2_to_l1_ns;
 	*l2_runtime_agg_ptr = l2_runtime_ns;
-	vcpu->arch.l1_to_l2_cs = l1_to_l2_ns;
-	vcpu->arch.l2_to_l1_cs = l2_to_l1_ns;
-	vcpu->arch.l2_runtime_agg = l2_runtime_ns;
 }
 
 u64 kvmhv_get_l1_to_l2_cs_time(void)
-- 
2.54.0

[PATCH v2 2/3] powerpc/perf: Use the aggregate context switch values from vcpu struct

[Gautam Menghani]

The vpa-pmu driver reports incorrect numbers in 2 scenarios:

1. The vCPU process gets rescheduled to a different host cpu
    - Incorrect numbers are observed here because the PACA is per-host cpu
      resource, and the KVM vCPUs can be rescheduled to different
      host cpus. This causes the vpa-pmu driver to subtract wrong values
      when vCPUs are rescheduled.

2. The vCPU is not running when vpa_pmu_read() is called.
    - In this case get_counter_data() returns 0, and this can result in
      negative numbers getting reported.

Fix the above issues by using the aggregate values from the vcpu
structure to capture and report the difference in counter values.

Fixes: 176cda0619b6 ("powerpc/perf: Add perf interface to expose vpa counters")
Cc: <stable@vger.kernel.org>
Signed-off-by: Gautam Menghani <gautam@linux.ibm.com>
---
v1 -> v2:
1. Fix the output for "perf stat --cpu ..."
2. Add stable/fixes tags

 arch/powerpc/include/asm/kvm_book3s_64.h |  3 --
 arch/powerpc/kvm/book3s_hv.c             | 45 ------------------------
 arch/powerpc/perf/vpa-pmu.c              | 24 +++++++++----
 3 files changed, 18 insertions(+), 54 deletions(-)

diff --git a/arch/powerpc/include/asm/kvm_book3s_64.h b/arch/powerpc/include/asm/kvm_book3s_64.h
index b936e174eefd..f620e3126d68 100644
--- a/arch/powerpc/include/asm/kvm_book3s_64.h
+++ b/arch/powerpc/include/asm/kvm_book3s_64.h
@@ -691,9 +691,6 @@ void kvmhv_set_l2_counters_status(int cpu, bool status);
 u64 kvmhv_get_l1_to_l2_cs_time(void);
 u64 kvmhv_get_l2_to_l1_cs_time(void);
 u64 kvmhv_get_l2_runtime_agg(void);
-u64 kvmhv_get_l1_to_l2_cs_time_vcpu(void);
-u64 kvmhv_get_l2_to_l1_cs_time_vcpu(void);
-u64 kvmhv_get_l2_runtime_agg_vcpu(void);
 
 #endif /* CONFIG_KVM_BOOK3S_HV_POSSIBLE */
 
diff --git a/arch/powerpc/kvm/book3s_hv.c b/arch/powerpc/kvm/book3s_hv.c
index 342168b8bfc8..b9285b7f1fed 100644
--- a/arch/powerpc/kvm/book3s_hv.c
+++ b/arch/powerpc/kvm/book3s_hv.c
@@ -4189,51 +4189,6 @@ u64 kvmhv_get_l2_runtime_agg(void)
 }
 EXPORT_SYMBOL(kvmhv_get_l2_runtime_agg);
 
-u64 kvmhv_get_l1_to_l2_cs_time_vcpu(void)
-{
-	struct kvm_vcpu *vcpu;
-	struct kvm_vcpu_arch *arch;
-
-	vcpu = local_paca->kvm_hstate.kvm_vcpu;
-	if (vcpu) {
-		arch = &vcpu->arch;
-		return arch->l1_to_l2_cs;
-	} else {
-		return 0;
-	}
-}
-EXPORT_SYMBOL(kvmhv_get_l1_to_l2_cs_time_vcpu);
-
-u64 kvmhv_get_l2_to_l1_cs_time_vcpu(void)
-{
-	struct kvm_vcpu *vcpu;
-	struct kvm_vcpu_arch *arch;
-
-	vcpu = local_paca->kvm_hstate.kvm_vcpu;
-	if (vcpu) {
-		arch = &vcpu->arch;
-		return arch->l2_to_l1_cs;
-	} else {
-		return 0;
-	}
-}
-EXPORT_SYMBOL(kvmhv_get_l2_to_l1_cs_time_vcpu);
-
-u64 kvmhv_get_l2_runtime_agg_vcpu(void)
-{
-	struct kvm_vcpu *vcpu;
-	struct kvm_vcpu_arch *arch;
-
-	vcpu = local_paca->kvm_hstate.kvm_vcpu;
-	if (vcpu) {
-		arch = &vcpu->arch;
-		return arch->l2_runtime_agg;
-	} else {
-		return 0;
-	}
-}
-EXPORT_SYMBOL(kvmhv_get_l2_runtime_agg_vcpu);
-
 #else
 int kvmhv_get_l2_counters_status(void)
 {
diff --git a/arch/powerpc/perf/vpa-pmu.c b/arch/powerpc/perf/vpa-pmu.c
index bff4cfab7b94..e79d98447c74 100644
--- a/arch/powerpc/perf/vpa-pmu.c
+++ b/arch/powerpc/perf/vpa-pmu.c
@@ -91,7 +91,7 @@ static int vpa_pmu_event_init(struct perf_event *event)
 	return 0;
 }
 
-static unsigned long get_counter_data(struct perf_event *event)
+static unsigned long get_counter_data(struct kvm_vcpu *vcpu, struct perf_event *event)
 {
 	unsigned int config = event->attr.config;
 	u64 data;
@@ -99,19 +99,19 @@ static unsigned long get_counter_data(struct perf_event *event)
 	switch (config) {
 	case L1_TO_L2_CS_LAT:
 		if (event->attach_state & PERF_ATTACH_TASK)
-			data = kvmhv_get_l1_to_l2_cs_time_vcpu();
+			data = vcpu->arch.l1_to_l2_cs;
 		else
 			data = kvmhv_get_l1_to_l2_cs_time();
 		break;
 	case L2_TO_L1_CS_LAT:
 		if (event->attach_state & PERF_ATTACH_TASK)
-			data = kvmhv_get_l2_to_l1_cs_time_vcpu();
+			data = vcpu->arch.l2_to_l1_cs;
 		else
 			data = kvmhv_get_l2_to_l1_cs_time();
 		break;
 	case L2_RUNTIME_AGG:
 		if (event->attach_state & PERF_ATTACH_TASK)
-			data = kvmhv_get_l2_runtime_agg_vcpu();
+			data = vcpu->arch.l2_runtime_agg;
 		else
 			data = kvmhv_get_l2_runtime_agg();
 		break;
@@ -126,21 +126,33 @@ static unsigned long get_counter_data(struct perf_event *event)
 static int vpa_pmu_add(struct perf_event *event, int flags)
 {
 	u64 data;
+	struct kvm_vcpu *vcpu;
 
+	vcpu = local_paca->kvm_hstate.kvm_vcpu;
+	if (!vcpu)
+		goto out;
+
+	event->pmu_private = vcpu;
 	kvmhv_set_l2_counters_status(smp_processor_id(), true);
 
-	data = get_counter_data(event);
+	data = get_counter_data(vcpu, event);
 	local64_set(&event->hw.prev_count, data);
 
+out:
 	return 0;
 }
 
 static void vpa_pmu_read(struct perf_event *event)
 {
 	u64 prev_data, new_data, final_data;
+	struct kvm_vcpu *vcpu;
+
+	vcpu = (struct kvm_vcpu *) event->pmu_private;
+	if (!vcpu)
+		return;
 
 	prev_data = local64_read(&event->hw.prev_count);
-	new_data = get_counter_data(event);
+	new_data = get_counter_data(vcpu, event);
 	final_data = new_data - prev_data;
 
 	local64_add(final_data, &event->count);
-- 
2.54.0

[PATCH v2 3/3] powerpc/perf: Update prev_count of event to get accurate values

[Gautam Menghani]

When vpa_pmu_read() is called twice while a process is running on a cpu,
the "event->hw.prev_count" variable returns a stale value on the 2nd
read which results in a larger value getting added to event->count.

Fix this by updating the event->hw.prev_count every time vpa_pmu_read()
is called.

Fixes: 176cda0619b6 ("powerpc/perf: Add perf interface to expose vpa counters")
Cc: <stable@vger.kernel.org>
Signed-off-by: Gautam Menghani <gautam@linux.ibm.com>
---
v1 -> v2:
1. Add stable/fixes tags.

 arch/powerpc/perf/vpa-pmu.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/powerpc/perf/vpa-pmu.c b/arch/powerpc/perf/vpa-pmu.c
index e79d98447c74..efc39f71553b 100644
--- a/arch/powerpc/perf/vpa-pmu.c
+++ b/arch/powerpc/perf/vpa-pmu.c
@@ -156,6 +156,7 @@ static void vpa_pmu_read(struct perf_event *event)
 	final_data = new_data - prev_data;
 
 	local64_add(final_data, &event->count);
+	local64_set(&event->hw.prev_count, new_data);
 }
 
 static void vpa_pmu_del(struct perf_event *event, int flags)
-- 
2.54.0

Re: [PATCH v2 2/3] powerpc/perf: Use the aggregate context switch values from vcpu struct

[Gautam Menghani]

On Thu, Aug 13, 2026 at 09:58:50AM +0000, sashiko-bot@kernel.org wrote:
> Thank you for your contribution! Sashiko AI review found 5 potential issue(s) to consider:
> 
> New issues:
> - [High] Task-bound PMU events cache a stale vCPU pointer, resulting in tracking the wrong vCPU.
> - [High] CPU-wide and system-wide PMU events are broken and silently report 0 if added when no guest is running.
> - [High] Uninitialized event state on task migration leaks stale vCPU pointers.
> - [Medium] Unbalanced disablement of the global hardware PMU counters.
> 
> Pre-existing issues:
> - [Critical] Dereferencing `kvm_hstate.kvm_vcpu` leads to a Use-After-Free if the previously running VM has been destroyed.
> --
> 
> --- Patch [2]: [PATCH v2 2/3] powerpc/perf: Use the aggregate context switch values from vcpu struct ---
> commit e328e1f6c8baf0140410c1983f559e87d1d0efdc
> Author: Gautam Menghani <gautam@linux.ibm.com>
> powerpc/perf: Use the aggregate context switch values from vcpu struct
> 
> This commit aims to fix inaccurate vpa-pmu counter reporting during vCPU
> migrations and when vCPUs are not running by fetching aggregate values
> from the vcpu struct instead of relying on the host cpu's PACA.
> 
> > diff --git a/arch/powerpc/perf/vpa-pmu.c b/arch/powerpc/perf/vpa-pmu.c
> > --- a/arch/powerpc/perf/vpa-pmu.c
> > +++ b/arch/powerpc/perf/vpa-pmu.c
> [ ... ]
> > @@ -99,19 +99,19 @@ static unsigned long get_counter_data(struct perf_event *event)
> >  	switch (config) {
> >  	case L1_TO_L2_CS_LAT:
> >  		if (event->attach_state & PERF_ATTACH_TASK)
> > -			data = kvmhv_get_l1_to_l2_cs_time_vcpu();
> > +			data = vcpu->arch.l1_to_l2_cs;
> 
> [Severity: Critical]
> This is a pre-existing issue, but does dereferencing the vcpu pointer here
> lead to a use-after-free if the previously running VM has been destroyed?
> 
> When KVM exits a guest, it does not clear local_paca->kvm_hstate.kvm_vcpu,
> leaving a dangling pointer in the host's PACA. 
> 
> The PMU driver reads this dangling pointer in vpa_pmu_add() and permanently
> caches it in event->pmu_private. Subsequent calls to vpa_pmu_read() pass
> this cached pointer to get_counter_data(), which dereferences the freed
> memory here.
> 
> >  		else
> >  			data = kvmhv_get_l1_to_l2_cs_time();
> >  		break;
> [ ... ]
> > @@ -126,21 +126,33 @@ static int vpa_pmu_add(struct perf_event *event, int flags)
> >  {
> >  	u64 data;
> > +	struct kvm_vcpu *vcpu;
> >  
> > +	vcpu = local_paca->kvm_hstate.kvm_vcpu;
> > +	if (!vcpu)
> > +		goto out;
> 

A dangling pointer is stored, but will that cause a UAF? When tracing a
particular tid/pid, the perf stat command exits if the pid (guest) is destroyed.

> [Severity: High]
> Does this early exit break CPU-wide and system-wide profiling?
> 
> If a user initiates a CPU-wide profiling session (e.g. perf stat -a) and no
> guest is actively running on that specific CPU at that moment, vcpu is NULL.
> The function exits early returning 0 without initializing event->pmu_private
> or event->hw.prev_count. 
> 
> Subsequent calls to vpa_pmu_read() check if (!vcpu) and immediately return,
> silently leaving the event counter permanently at 0.

The vpa-pmu driver is only meant to report context switch times of individual
vCPUs. So reporting 0 when a vCPU is not running is expected behaviour.

> 
> [Severity: High]
> Could this early exit also leak state from a previous CPU when a task
> migrates?
> 
> When a task with a vpa_pmu event migrates to a new CPU, perf core calls
> pmu->del on the old CPU and pmu->add on the new CPU. If vcpu is NULL on the
> new CPU, it returns 0 (success) but jumps to out without updating or
> clearing event->pmu_private. 
> 
> The event silently retains the old vcpu pointer and prev_count from the
> previous CPU, resulting in corrupted profiling data calculated against an
> unrelated CPU's context.

Yes, valid point.

> 
> [Severity: Medium]
> Are the global hardware PMU counters skipped here on early bailout, leading
> to an unbalanced disablement later?
> 
> If a user creates a PMU event on a CPU where no vCPU is active, this early
> exit skips calling kvmhv_set_l2_counters_status(cpu, true). 
> 
> However, when the event is deleted or scheduled out, vpa_pmu_del()
> unconditionally calls kvmhv_set_l2_counters_status(cpu, false). This
> unbalanced behavior forcefully disables the hardware counters even when they
> were never enabled, which could break legitimate concurrent KVM tracing
> sessions.

Valid find - in vpa_pmu_del() the counters should be disabled only if they
were enabled in vpa_pmu_add()

> 
> > +
> > +	event->pmu_private = vcpu;
> 
> [Severity: High]
> Is it possible caching the vcpu pointer here results in tracking the wrong
> vCPU for task-bound events?
> 
> When a user creates a task-bound vpa_pmu perf event, the core perf
> subsystem calls vpa_pmu_add() during perf_event_context_sched_in(). At this
> point, the task has been scheduled but has not yet invoked the KVM_RUN
> ioctl.
> 
> Because of this, local_paca->kvm_hstate.kvm_vcpu does not point to the
> incoming task's vCPU; it contains a stale pointer to the last vCPU that
> executed on this physical host CPU. Caching this pointer permanently means
> the event tracks unrelated data.

Valid find, will fix

> 
> >  	kvmhv_set_l2_counters_status(smp_processor_id(), true);
> >  
> > -	data = get_counter_data(event);
> > +	data = get_counter_data(vcpu, event);
> >  	local64_set(&event->hw.prev_count, data);
> >  
> > +out:
> >  	return 0;
> >  }
> 
> -- 
> Sashiko AI review · https://sashiko.dev/#/patchset/20260813094535.10083-1-gautam@linux.ibm.com?part=2

Re: [PATCH v2 3/3] powerpc/perf: Update prev_count of event to get accurate values

[Gautam Menghani]

On Thu, Aug 13, 2026 at 10:01:02AM +0000, sashiko-bot@kernel.org wrote:
> Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
> 
> New issues:
> - [Medium] Missing atomic cmpxchg loop in vpa_pmu_read() when updating prev_count.
> 
> Pre-existing issues:
> - [High] The VPA PMU `add` callback stores a raw pointer to `struct kvm_vcpu` in `event->pmu_private` without reference counting, leading to a Use-After-Free.
> --
> 
> --- Patch [3]: [PATCH v2 3/3] powerpc/perf: Update prev_count of event to get accurate values ---
> commit 7c392d724ba481a5282a90aed95397fac4533493
> Author: Gautam Menghani <gautam@linux.ibm.com>
> 
> powerpc/perf: Update prev_count of event to get accurate values
> 
> This patch updates the VPA PMU read function to keep event->hw.prev_count
> current. This prevents stale values from being returned on consecutive reads
> while a process is running on a CPU.
> 
> > diff --git a/arch/powerpc/perf/vpa-pmu.c b/arch/powerpc/perf/vpa-pmu.c
> > index e79d98447c743..efc39f71553bf 100644
> > --- a/arch/powerpc/perf/vpa-pmu.c
> > +++ b/arch/powerpc/perf/vpa-pmu.c
> > @@ -156,6 +156,7 @@ static void vpa_pmu_read(struct perf_event *event)
> >  	final_data = new_data - prev_data;
> >  
> >  	local64_add(final_data, &event->count);
> > +	local64_set(&event->hw.prev_count, new_data);
> 
> [Severity: Medium]
> Is it safe to use local64_set() here without a local64_cmpxchg() loop?
> 
> If vpa_pmu_read() is interrupted by an NMI (such as a hardware PMI) and a BPF
> program attached to the NMI reads the same event via bpf_perf_event_read(),
> the nested read will calculate its delta and update prev_count.
> 
> When the outer vpa_pmu_read() resumes, it could calculate its delta using the
> old prev_data (resulting in double-counting the inner delta) and then
> non-atomically overwrite prev_count.
> 
> Should this use a local64_cmpxchg() loop to safely update prev_count?

Yes, valid point.

> 
> >  }
> >  
> >  static void vpa_pmu_del(struct perf_event *event, int flags)
> 
> [Severity: High]
> This is a pre-existing issue, but does this code leave a stale vcpu pointer
> in event->pmu_private that can lead to a use-after-free?
> 
> Looking at vpa_pmu_add(), a raw pointer to struct kvm_vcpu is stored without
> taking a reference:
> 
> arch/powerpc/perf/vpa-pmu.c:vpa_pmu_add() {
>     ...
>     vcpu = local_paca->kvm_hstate.kvm_vcpu;
>     if (!vcpu)
>         goto out;
>     ...
>     event->pmu_private = vcpu;
> }
> 
> When the thread context-switches out, vpa_pmu_del() stops the event but
> does not clear event->pmu_private to NULL. When the thread is scheduled
> back in outside of KVM, vpa_pmu_add() sees the vcpu is NULL and returns
> early, leaving the event active with the stale vcpu pointer.
> 
> If the VM is then destroyed and the vcpu freed, would a subsequent thread
> exit or user read() calling vpa_pmu_read() trigger a use-after-free when
> dereferencing vcpu->arch.l1_to_l2_cs?
> 

Valid find, will fix in v3.

> -- 
> Sashiko AI review · https://sashiko.dev/#/patchset/20260813094535.10083-1-gautam@linux.ibm.com?part=3