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

[PATCH v3 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 of 2 issues:

1. The PACA never points to the correct vCPU running on a host vCPU when
vpa_pmu_add() is called.

2. When get_counter_data() reads the PACA counter values, it does not
update the event->hw.prev_count.


Changes in V3:
1. Drop the usage of the PACA's vCPU pointer.
2. Introduce a new patch to fix an issue seen when a tracepoint and vpa-pmu
driver concurrently enable/disable access to latency counters in VPA.


Gautam Menghani (3):
  Revert "powerpc/perf: Add per-task/process monitoring to vpa_pmu
    driver"
  powerpc/perf: Update prev_count of event to get accurate values
  KVM: PPC: Book3s HV: Ensure reliable usage of latency counters

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

-- 
2.56.0

[PATCH v3 1/3] Revert "powerpc/perf: Add per-task/process monitoring to vpa_pmu driver"

[Gautam Menghani]

This reverts commit f26f9933e3e31b2117b804b6b8932388db88a131.

The local_paca holds a pointer to the vCPU currently running on the given
host CPU. When the vpa-pmu driver tries to get the vCPU pointer from
local_paca, it either receives NULL or the pointer to the vCPU which was
running on that host CPU previously. This is because the vCPU pointer in
PACA is updated by kvmhv_run_single_vcpu(), which runs after
vpa_pmu_add(). Also, on vCPU exit, the vCPU pointer in PACA is never
cleared. This results in incorrect numbers being reported by the vpa-pmu
driver.

Fix the problem by avoiding the use of vCPU pointer in PACA altogether.
When a vCPU is scheduled in and out on a host vCPU, vpa_pmu_add() and
vpa_pmu_del() can already calculate the correct latency values in
event->count. Drop the usage of the vCPU pointer in PACA and just rely
on the VPA counter values.

Fixes: f26f9933e3e3 ("powerpc/perf: Add per-task/process monitoring to vpa_pmu driver")
Cc: <stable@vger.kernel.org>
Signed-off-by: Gautam Menghani <gautam@linux.ibm.com>
---
 arch/powerpc/include/asm/kvm_book3s_64.h |  3 --
 arch/powerpc/kvm/book3s_hv.c             | 45 ------------------------
 arch/powerpc/perf/vpa-pmu.c              | 15 ++------
 3 files changed, 3 insertions(+), 60 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 22283d46e8fe..5fa6f93548ad 100644
--- a/arch/powerpc/kvm/book3s_hv.c
+++ b/arch/powerpc/kvm/book3s_hv.c
@@ -4212,51 +4212,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..01d9196fcb0f 100644
--- a/arch/powerpc/perf/vpa-pmu.c
+++ b/arch/powerpc/perf/vpa-pmu.c
@@ -98,22 +98,13 @@ 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();
-		else
-			data = kvmhv_get_l1_to_l2_cs_time();
+		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();
-		else
-			data = kvmhv_get_l2_to_l1_cs_time();
+		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();
-		else
-			data = kvmhv_get_l2_runtime_agg();
+		data = kvmhv_get_l2_runtime_agg();
 		break;
 	default:
 		data = 0;
-- 
2.56.0

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

[Gautam Menghani]

When vpa_pmu_read() is called twice while a vCPU is running on the same
host cpu, the "event->hw.prev_count" variable returns the same old 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>
---
v2 -> v3:
1. Use local64_xchg for atomic update.

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 01d9196fcb0f..3296877eb317 100644
--- a/arch/powerpc/perf/vpa-pmu.c
+++ b/arch/powerpc/perf/vpa-pmu.c
@@ -132,6 +132,7 @@ static void vpa_pmu_read(struct perf_event *event)
 
 	prev_data = local64_read(&event->hw.prev_count);
 	new_data = get_counter_data(event);
+	prev_data = local64_xchg(&event->hw.prev_count, new_data);
 	final_data = new_data - prev_data;
 
 	local64_add(final_data, &event->count);
-- 
2.56.0

[PATCH v3 3/3] KVM: PPC: Book3s HV: Ensure reliable usage of latency counters

[Gautam Menghani]

The kvmppc_vcpu_stats tracepoint and the vpa-pmu driver can both enable
and disable the latency counters in the VPA. When both are used
together, they can step on each other and produce unreliable numbers.
Since the VPA element for enabling/disabling counters
(l2_counters_enable) continues counting with any value > 0, introduce a
spinlock to ensure that the tracepoint and vpa-pmu driver can work
correctly together.

Fixes: e1f288d2f9c6 ("KVM: PPC: Book3S HV nestedv2: Add support for reading VPA counters for pseries guests")
Cc: stable@vger.kernel.org
Signed-off-by: Gautam Menghani <gautam@linux.ibm.com>
---
 arch/powerpc/kvm/book3s_hv.c | 9 +++++++--
 1 file changed, 7 insertions(+), 2 deletions(-)

diff --git a/arch/powerpc/kvm/book3s_hv.c b/arch/powerpc/kvm/book3s_hv.c
index 5fa6f93548ad..e1bde3c6b0c4 100644
--- a/arch/powerpc/kvm/book3s_hv.c
+++ b/arch/powerpc/kvm/book3s_hv.c
@@ -4142,14 +4142,19 @@ int kvmhv_get_l2_counters_status(void)
 		get_lppaca()->l2_counters_enable;
 }
 
+static DEFINE_RAW_SPINLOCK(l2_counters_lock);
 void kvmhv_set_l2_counters_status(int cpu, bool status)
 {
+	unsigned long flags;
+
 	if (!firmware_has_feature(FW_FEATURE_LPAR))
 		return;
+	raw_spin_lock_irqsave(&l2_counters_lock, flags);
 	if (status)
-		lppaca_of(cpu).l2_counters_enable = 1;
+		lppaca_of(cpu).l2_counters_enable++;
 	else
-		lppaca_of(cpu).l2_counters_enable = 0;
+		lppaca_of(cpu).l2_counters_enable--;
+	raw_spin_unlock_irqrestore(&l2_counters_lock, flags);
 }
 EXPORT_SYMBOL(kvmhv_set_l2_counters_status);
 
-- 
2.56.0

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

[Gautam Menghani]

Forgot to add linuxppc-dev

On Fri, Nov 06, 2026 at 09:01:31PM +0530, Gautam Menghani wrote:
> 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 of 2 issues:
> 
> 1. The PACA never points to the correct vCPU running on a host vCPU when
> vpa_pmu_add() is called.
> 
> 2. When get_counter_data() reads the PACA counter values, it does not
> update the event->hw.prev_count.
> 
> 
> Changes in V3:
> 1. Drop the usage of the PACA's vCPU pointer.
> 2. Introduce a new patch to fix an issue seen when a tracepoint and vpa-pmu
> driver concurrently enable/disable access to latency counters in VPA.
> 
> 
> Gautam Menghani (3):
>   Revert "powerpc/perf: Add per-task/process monitoring to vpa_pmu
>     driver"
>   powerpc/perf: Update prev_count of event to get accurate values
>   KVM: PPC: Book3s HV: Ensure reliable usage of latency counters
> 
>  arch/powerpc/include/asm/kvm_book3s_64.h |  3 --
>  arch/powerpc/kvm/book3s_hv.c             | 54 +++---------------------
>  arch/powerpc/perf/vpa-pmu.c              | 16 ++-----
>  3 files changed, 11 insertions(+), 62 deletions(-)
> 
> -- 
> 2.56.0
>