* [kvm-unit-tests patch v3 1/8] x86/pmu: Add helper to detect Intel overcount issues
2025-09-03 6:45 [kvm-unit-tests patch v3 0/8] Fix pmu test errors on GNR/SRF/CWF Dapeng Mi
@ 2025-09-03 6:45 ` Dapeng Mi
2025-11-20 22:27 ` Sean Christopherson
2025-09-03 6:45 ` [kvm-unit-tests patch v3 2/8] x86/pmu: Relax precise count validation for Intel overcounted platforms Dapeng Mi
` (7 subsequent siblings)
8 siblings, 1 reply; 16+ messages in thread
From: Dapeng Mi @ 2025-09-03 6:45 UTC (permalink / raw)
To: Sean Christopherson, Paolo Bonzini
Cc: kvm, linux-kernel, Jim Mattson, Mingwei Zhang, Zide Chen,
Das Sandipan, Shukla Manali, Xiaoyao Li, Dapeng Mi, dongsheng,
Dapeng Mi, Yi Lai
From: dongsheng <dongsheng.x.zhang@intel.com>
For Intel Atom CPUs, the PMU events "Instruction Retired" or
"Branch Instruction Retired" may be overcounted for some certain
instructions, like FAR CALL/JMP, RETF, IRET, VMENTRY/VMEXIT/VMPTRLD
and complex SGX/SMX/CSTATE instructions/flows.
The detailed information can be found in the errata (section SRF7):
https://edc.intel.com/content/www/us/en/design/products-and-solutions/processors-and-chipsets/sierra-forest/xeon-6700-series-processor-with-e-cores-specification-update/errata-details/
For the Atom platforms before Sierra Forest (including Sierra Forest),
Both 2 events "Instruction Retired" and "Branch Instruction Retired" would
be overcounted on these certain instructions, but for Clearwater Forest
only "Instruction Retired" event is overcounted on these instructions.
So add a helper detect_inst_overcount_flags() to detect whether the
platform has the overcount issue and the later patches would relax the
precise count check by leveraging the gotten overcount flags from this
helper.
Signed-off-by: dongsheng <dongsheng.x.zhang@intel.com>
[Rewrite comments and commit message - Dapeng]
Signed-off-by: Dapeng Mi <dapeng1.mi@linux.intel.com>
Tested-by: Yi Lai <yi1.lai@intel.com>
---
lib/x86/processor.h | 27 ++++++++++++++++++++++++++
x86/pmu.c | 47 +++++++++++++++++++++++++++++++++++++++++++++
2 files changed, 74 insertions(+)
diff --git a/lib/x86/processor.h b/lib/x86/processor.h
index 62f3d578..937f75e4 100644
--- a/lib/x86/processor.h
+++ b/lib/x86/processor.h
@@ -1188,4 +1188,31 @@ static inline bool is_lam_u57_enabled(void)
return !!(read_cr3() & X86_CR3_LAM_U57);
}
+/* Copy from kernel arch/x86/lib/cpu.c */
+static inline u32 x86_family(u32 sig)
+{
+ u32 x86;
+
+ x86 = (sig >> 8) & 0xf;
+
+ if (x86 == 0xf)
+ x86 += (sig >> 20) & 0xff;
+
+ return x86;
+}
+
+static inline u32 x86_model(u32 sig)
+{
+ u32 fam, model;
+
+ fam = x86_family(sig);
+
+ model = (sig >> 4) & 0xf;
+
+ if (fam >= 0x6)
+ model += ((sig >> 16) & 0xf) << 4;
+
+ return model;
+}
+
#endif
diff --git a/x86/pmu.c b/x86/pmu.c
index a6b0cfcc..87365aff 100644
--- a/x86/pmu.c
+++ b/x86/pmu.c
@@ -159,6 +159,14 @@ static struct pmu_event *gp_events;
static unsigned int gp_events_size;
static unsigned int fixed_counters_num;
+/*
+ * Flags for Intel "Instruction Retired" and "Branch Instruction Retired"
+ * overcount flaws.
+ */
+#define INST_RETIRED_OVERCOUNT BIT(0)
+#define BR_RETIRED_OVERCOUNT BIT(1)
+static u32 intel_inst_overcount_flags;
+
static int has_ibpb(void)
{
return this_cpu_has(X86_FEATURE_SPEC_CTRL) ||
@@ -959,6 +967,43 @@ static void check_invalid_rdpmc_gp(void)
"Expected #GP on RDPMC(64)");
}
+/*
+ * For Intel Atom CPUs, the PMU events "Instruction Retired" or
+ * "Branch Instruction Retired" may be overcounted for some certain
+ * instructions, like FAR CALL/JMP, RETF, IRET, VMENTRY/VMEXIT/VMPTRLD
+ * and complex SGX/SMX/CSTATE instructions/flows.
+ *
+ * The detailed information can be found in the errata (section SRF7):
+ * https://edc.intel.com/content/www/us/en/design/products-and-solutions/processors-and-chipsets/sierra-forest/xeon-6700-series-processor-with-e-cores-specification-update/errata-details/
+ *
+ * For the Atom platforms before Sierra Forest (including Sierra Forest),
+ * Both 2 events "Instruction Retired" and "Branch Instruction Retired" would
+ * be overcounted on these certain instructions, but for Clearwater Forest
+ * only "Instruction Retired" event is overcounted on these instructions.
+ */
+static u32 detect_inst_overcount_flags(void)
+{
+ u32 flags = 0;
+ struct cpuid c = cpuid(1);
+
+ if (x86_family(c.a) == 0x6) {
+ switch (x86_model(c.a)) {
+ case 0xDD: /* Clearwater Forest */
+ flags = INST_RETIRED_OVERCOUNT;
+ break;
+
+ case 0xAF: /* Sierra Forest */
+ case 0x4D: /* Avaton, Rangely */
+ case 0x5F: /* Denverton */
+ case 0x86: /* Jacobsville */
+ flags = INST_RETIRED_OVERCOUNT | BR_RETIRED_OVERCOUNT;
+ break;
+ }
+ }
+
+ return flags;
+}
+
int main(int ac, char **av)
{
int instruction_idx;
@@ -985,6 +1030,8 @@ int main(int ac, char **av)
branch_idx = INTEL_BRANCHES_IDX;
branch_miss_idx = INTEL_BRANCH_MISS_IDX;
+ intel_inst_overcount_flags = detect_inst_overcount_flags();
+
/*
* For legacy Intel CPUS without clflush/clflushopt support,
* there is no way to force to trigger a LLC miss, thus set
--
2.34.1
^ permalink raw reply related [flat|nested] 16+ messages in thread* Re: [kvm-unit-tests patch v3 1/8] x86/pmu: Add helper to detect Intel overcount issues
2025-09-03 6:45 ` [kvm-unit-tests patch v3 1/8] x86/pmu: Add helper to detect Intel overcount issues Dapeng Mi
@ 2025-11-20 22:27 ` Sean Christopherson
2025-11-21 1:18 ` Mi, Dapeng
0 siblings, 1 reply; 16+ messages in thread
From: Sean Christopherson @ 2025-11-20 22:27 UTC (permalink / raw)
To: Dapeng Mi
Cc: Paolo Bonzini, kvm, linux-kernel, Jim Mattson, Mingwei Zhang,
Zide Chen, Das Sandipan, Shukla Manali, Xiaoyao Li, Dapeng Mi,
dongsheng, Yi Lai
On Wed, Sep 03, 2025, Dapeng Mi wrote:
> From: dongsheng <dongsheng.x.zhang@intel.com>
>
> For Intel Atom CPUs, the PMU events "Instruction Retired" or
> "Branch Instruction Retired" may be overcounted for some certain
> instructions, like FAR CALL/JMP, RETF, IRET, VMENTRY/VMEXIT/VMPTRLD
> and complex SGX/SMX/CSTATE instructions/flows.
>
> The detailed information can be found in the errata (section SRF7):
> https://edc.intel.com/content/www/us/en/design/products-and-solutions/processors-and-chipsets/sierra-forest/xeon-6700-series-processor-with-e-cores-specification-update/errata-details/
>
> For the Atom platforms before Sierra Forest (including Sierra Forest),
> Both 2 events "Instruction Retired" and "Branch Instruction Retired" would
> be overcounted on these certain instructions, but for Clearwater Forest
> only "Instruction Retired" event is overcounted on these instructions.
>
> So add a helper detect_inst_overcount_flags() to detect whether the
> platform has the overcount issue and the later patches would relax the
> precise count check by leveraging the gotten overcount flags from this
> helper.
>
> Signed-off-by: dongsheng <dongsheng.x.zhang@intel.com>
> [Rewrite comments and commit message - Dapeng]
> Signed-off-by: Dapeng Mi <dapeng1.mi@linux.intel.com>
> Tested-by: Yi Lai <yi1.lai@intel.com>
> ---
> lib/x86/processor.h | 27 ++++++++++++++++++++++++++
> x86/pmu.c | 47 +++++++++++++++++++++++++++++++++++++++++++++
> 2 files changed, 74 insertions(+)
>
> diff --git a/lib/x86/processor.h b/lib/x86/processor.h
> index 62f3d578..937f75e4 100644
> --- a/lib/x86/processor.h
> +++ b/lib/x86/processor.h
> @@ -1188,4 +1188,31 @@ static inline bool is_lam_u57_enabled(void)
> return !!(read_cr3() & X86_CR3_LAM_U57);
> }
>
> +/* Copy from kernel arch/x86/lib/cpu.c */
Eh, just drop this, we don't care if the kernel code changes, this is all based
on architectural behavior.
> +static inline u32 x86_family(u32 sig)
> +{
> + u32 x86;
> +
> + x86 = (sig >> 8) & 0xf;
> +
> + if (x86 == 0xf)
> + x86 += (sig >> 20) & 0xff;
> +
> + return x86;
> +}
> +
> +static inline u32 x86_model(u32 sig)
> +{
> + u32 fam, model;
> +
> + fam = x86_family(sig);
> +
> + model = (sig >> 4) & 0xf;
> +
> + if (fam >= 0x6)
> + model += ((sig >> 16) & 0xf) << 4;
> +
> + return model;
> +}
We should place these up near is_intel() so that it's more obviously what "family"
and "model" mean (should be obvious already, but it's an easy thing to do).
> +/*
> + * For Intel Atom CPUs, the PMU events "Instruction Retired" or
> + * "Branch Instruction Retired" may be overcounted for some certain
> + * instructions, like FAR CALL/JMP, RETF, IRET, VMENTRY/VMEXIT/VMPTRLD
> + * and complex SGX/SMX/CSTATE instructions/flows.
> + *
> + * The detailed information can be found in the errata (section SRF7):
> + * https://edc.intel.com/content/www/us/en/design/products-and-solutions/processors-and-chipsets/sierra-forest/xeon-6700-series-processor-with-e-cores-specification-update/errata-details/
> + *
> + * For the Atom platforms before Sierra Forest (including Sierra Forest),
> + * Both 2 events "Instruction Retired" and "Branch Instruction Retired" would
> + * be overcounted on these certain instructions, but for Clearwater Forest
> + * only "Instruction Retired" event is overcounted on these instructions.
> + */
> +static u32 detect_inst_overcount_flags(void)
> +{
> + u32 flags = 0;
> + struct cpuid c = cpuid(1);
> +
> + if (x86_family(c.a) == 0x6) {
> + switch (x86_model(c.a)) {
> + case 0xDD: /* Clearwater Forest */
> + flags = INST_RETIRED_OVERCOUNT;
> + break;
> +
> + case 0xAF: /* Sierra Forest */
> + case 0x4D: /* Avaton, Rangely */
> + case 0x5F: /* Denverton */
> + case 0x86: /* Jacobsville */
> + flags = INST_RETIRED_OVERCOUNT | BR_RETIRED_OVERCOUNT;
> + break;
> + }
> + }
> +
> + return flags;
> +}
The errata tracking definitely belongs "struct pmu_caps pmu", and the init in
pmu_init().
^ permalink raw reply [flat|nested] 16+ messages in thread* Re: [kvm-unit-tests patch v3 1/8] x86/pmu: Add helper to detect Intel overcount issues
2025-11-20 22:27 ` Sean Christopherson
@ 2025-11-21 1:18 ` Mi, Dapeng
0 siblings, 0 replies; 16+ messages in thread
From: Mi, Dapeng @ 2025-11-21 1:18 UTC (permalink / raw)
To: Sean Christopherson
Cc: Paolo Bonzini, kvm, linux-kernel, Jim Mattson, Mingwei Zhang,
Zide Chen, Das Sandipan, Shukla Manali, Xiaoyao Li, Dapeng Mi,
dongsheng, Yi Lai
On 11/21/2025 6:27 AM, Sean Christopherson wrote:
> On Wed, Sep 03, 2025, Dapeng Mi wrote:
>> From: dongsheng <dongsheng.x.zhang@intel.com>
>>
>> For Intel Atom CPUs, the PMU events "Instruction Retired" or
>> "Branch Instruction Retired" may be overcounted for some certain
>> instructions, like FAR CALL/JMP, RETF, IRET, VMENTRY/VMEXIT/VMPTRLD
>> and complex SGX/SMX/CSTATE instructions/flows.
>>
>> The detailed information can be found in the errata (section SRF7):
>> https://edc.intel.com/content/www/us/en/design/products-and-solutions/processors-and-chipsets/sierra-forest/xeon-6700-series-processor-with-e-cores-specification-update/errata-details/
>>
>> For the Atom platforms before Sierra Forest (including Sierra Forest),
>> Both 2 events "Instruction Retired" and "Branch Instruction Retired" would
>> be overcounted on these certain instructions, but for Clearwater Forest
>> only "Instruction Retired" event is overcounted on these instructions.
>>
>> So add a helper detect_inst_overcount_flags() to detect whether the
>> platform has the overcount issue and the later patches would relax the
>> precise count check by leveraging the gotten overcount flags from this
>> helper.
>>
>> Signed-off-by: dongsheng <dongsheng.x.zhang@intel.com>
>> [Rewrite comments and commit message - Dapeng]
>> Signed-off-by: Dapeng Mi <dapeng1.mi@linux.intel.com>
>> Tested-by: Yi Lai <yi1.lai@intel.com>
>> ---
>> lib/x86/processor.h | 27 ++++++++++++++++++++++++++
>> x86/pmu.c | 47 +++++++++++++++++++++++++++++++++++++++++++++
>> 2 files changed, 74 insertions(+)
>>
>> diff --git a/lib/x86/processor.h b/lib/x86/processor.h
>> index 62f3d578..937f75e4 100644
>> --- a/lib/x86/processor.h
>> +++ b/lib/x86/processor.h
>> @@ -1188,4 +1188,31 @@ static inline bool is_lam_u57_enabled(void)
>> return !!(read_cr3() & X86_CR3_LAM_U57);
>> }
>>
>> +/* Copy from kernel arch/x86/lib/cpu.c */
> Eh, just drop this, we don't care if the kernel code changes, this is all based
> on architectural behavior.
>
>> +static inline u32 x86_family(u32 sig)
>> +{
>> + u32 x86;
>> +
>> + x86 = (sig >> 8) & 0xf;
>> +
>> + if (x86 == 0xf)
>> + x86 += (sig >> 20) & 0xff;
>> +
>> + return x86;
>> +}
>> +
>> +static inline u32 x86_model(u32 sig)
>> +{
>> + u32 fam, model;
>> +
>> + fam = x86_family(sig);
>> +
>> + model = (sig >> 4) & 0xf;
>> +
>> + if (fam >= 0x6)
>> + model += ((sig >> 16) & 0xf) << 4;
>> +
>> + return model;
>> +}
> We should place these up near is_intel() so that it's more obviously what "family"
> and "model" mean (should be obvious already, but it's an easy thing to do).
Yes.
>> +/*
>> + * For Intel Atom CPUs, the PMU events "Instruction Retired" or
>> + * "Branch Instruction Retired" may be overcounted for some certain
>> + * instructions, like FAR CALL/JMP, RETF, IRET, VMENTRY/VMEXIT/VMPTRLD
>> + * and complex SGX/SMX/CSTATE instructions/flows.
>> + *
>> + * The detailed information can be found in the errata (section SRF7):
>> + * https://edc.intel.com/content/www/us/en/design/products-and-solutions/processors-and-chipsets/sierra-forest/xeon-6700-series-processor-with-e-cores-specification-update/errata-details/
>> + *
>> + * For the Atom platforms before Sierra Forest (including Sierra Forest),
>> + * Both 2 events "Instruction Retired" and "Branch Instruction Retired" would
>> + * be overcounted on these certain instructions, but for Clearwater Forest
>> + * only "Instruction Retired" event is overcounted on these instructions.
>> + */
>> +static u32 detect_inst_overcount_flags(void)
>> +{
>> + u32 flags = 0;
>> + struct cpuid c = cpuid(1);
>> +
>> + if (x86_family(c.a) == 0x6) {
>> + switch (x86_model(c.a)) {
>> + case 0xDD: /* Clearwater Forest */
>> + flags = INST_RETIRED_OVERCOUNT;
>> + break;
>> +
>> + case 0xAF: /* Sierra Forest */
>> + case 0x4D: /* Avaton, Rangely */
>> + case 0x5F: /* Denverton */
>> + case 0x86: /* Jacobsville */
>> + flags = INST_RETIRED_OVERCOUNT | BR_RETIRED_OVERCOUNT;
>> + break;
>> + }
>> + }
>> +
>> + return flags;
>> +}
> The errata tracking definitely belongs "struct pmu_caps pmu", and the init in
> pmu_init().
Yes.
>
^ permalink raw reply [flat|nested] 16+ messages in thread
* [kvm-unit-tests patch v3 2/8] x86/pmu: Relax precise count validation for Intel overcounted platforms
2025-09-03 6:45 [kvm-unit-tests patch v3 0/8] Fix pmu test errors on GNR/SRF/CWF Dapeng Mi
2025-09-03 6:45 ` [kvm-unit-tests patch v3 1/8] x86/pmu: Add helper to detect Intel overcount issues Dapeng Mi
@ 2025-09-03 6:45 ` Dapeng Mi
2025-09-03 6:45 ` [kvm-unit-tests patch v3 3/8] x86/pmu: Fix incorrect masking of fixed counters Dapeng Mi
` (6 subsequent siblings)
8 siblings, 0 replies; 16+ messages in thread
From: Dapeng Mi @ 2025-09-03 6:45 UTC (permalink / raw)
To: Sean Christopherson, Paolo Bonzini
Cc: kvm, linux-kernel, Jim Mattson, Mingwei Zhang, Zide Chen,
Das Sandipan, Shukla Manali, Xiaoyao Li, Dapeng Mi, dongsheng,
Dapeng Mi, Yi Lai
From: dongsheng <dongsheng.x.zhang@intel.com>
As the VM-Exit/VM-Entry overcount issue on Intel Atom platforms,
there is no way to validate the precise count for "instructions" and
"branches" events on these overcounted Atom platforms. Thus relax the
precise count validation on these overcounted platforms.
Signed-off-by: dongsheng <dongsheng.x.zhang@intel.com>
Signed-off-by: Dapeng Mi <dapeng1.mi@linux.intel.com>
Tested-by: Yi Lai <yi1.lai@intel.com>
---
x86/pmu.c | 13 +++++++++----
1 file changed, 9 insertions(+), 4 deletions(-)
diff --git a/x86/pmu.c b/x86/pmu.c
index 87365aff..04946d10 100644
--- a/x86/pmu.c
+++ b/x86/pmu.c
@@ -237,10 +237,15 @@ static void adjust_events_range(struct pmu_event *gp_events,
* occur while running the measured code, e.g. if the host takes IRQs.
*/
if (pmu.is_intel && this_cpu_has_perf_global_ctrl()) {
- gp_events[instruction_idx].min = LOOP_INSNS;
- gp_events[instruction_idx].max = LOOP_INSNS;
- gp_events[branch_idx].min = LOOP_BRANCHES;
- gp_events[branch_idx].max = LOOP_BRANCHES;
+ if (!(intel_inst_overcount_flags & INST_RETIRED_OVERCOUNT)) {
+ gp_events[instruction_idx].min = LOOP_INSNS;
+ gp_events[instruction_idx].max = LOOP_INSNS;
+ }
+
+ if (!(intel_inst_overcount_flags & BR_RETIRED_OVERCOUNT)) {
+ gp_events[branch_idx].min = LOOP_BRANCHES;
+ gp_events[branch_idx].max = LOOP_BRANCHES;
+ }
}
/*
--
2.34.1
^ permalink raw reply related [flat|nested] 16+ messages in thread* [kvm-unit-tests patch v3 3/8] x86/pmu: Fix incorrect masking of fixed counters
2025-09-03 6:45 [kvm-unit-tests patch v3 0/8] Fix pmu test errors on GNR/SRF/CWF Dapeng Mi
2025-09-03 6:45 ` [kvm-unit-tests patch v3 1/8] x86/pmu: Add helper to detect Intel overcount issues Dapeng Mi
2025-09-03 6:45 ` [kvm-unit-tests patch v3 2/8] x86/pmu: Relax precise count validation for Intel overcounted platforms Dapeng Mi
@ 2025-09-03 6:45 ` Dapeng Mi
2025-11-20 22:28 ` Sean Christopherson
2025-09-03 6:45 ` [kvm-unit-tests patch v3 4/8] x86/pmu: Handle instruction overcount issue in overflow test Dapeng Mi
` (5 subsequent siblings)
8 siblings, 1 reply; 16+ messages in thread
From: Dapeng Mi @ 2025-09-03 6:45 UTC (permalink / raw)
To: Sean Christopherson, Paolo Bonzini
Cc: kvm, linux-kernel, Jim Mattson, Mingwei Zhang, Zide Chen,
Das Sandipan, Shukla Manali, Xiaoyao Li, Dapeng Mi, dongsheng,
Dapeng Mi, Yi Lai
From: dongsheng <dongsheng.x.zhang@intel.com>
The current implementation mistakenly limits the width of fixed counters
to the width of GP counters. Corrects the logic to ensure fixed counters
are properly masked according to their own width.
Opportunistically refine the GP counter bitwidth processing code.
Signed-off-by: dongsheng <dongsheng.x.zhang@intel.com>
Co-developed-by: Dapeng Mi <dapeng1.mi@linux.intel.com>
Signed-off-by: Dapeng Mi <dapeng1.mi@linux.intel.com>
Tested-by: Yi Lai <yi1.lai@intel.com>
---
x86/pmu.c | 8 +++-----
1 file changed, 3 insertions(+), 5 deletions(-)
diff --git a/x86/pmu.c b/x86/pmu.c
index 04946d10..44c728a5 100644
--- a/x86/pmu.c
+++ b/x86/pmu.c
@@ -556,18 +556,16 @@ static void check_counter_overflow(void)
int idx;
cnt.count = overflow_preset;
- if (pmu_use_full_writes())
- cnt.count &= (1ull << pmu.gp_counter_width) - 1;
-
if (i == pmu.nr_gp_counters) {
if (!pmu.is_intel)
break;
cnt.ctr = fixed_events[0].unit_sel;
- cnt.count = measure_for_overflow(&cnt);
- cnt.count &= (1ull << pmu.gp_counter_width) - 1;
+ cnt.count &= (1ull << pmu.fixed_counter_width) - 1;
} else {
cnt.ctr = MSR_GP_COUNTERx(i);
+ if (pmu_use_full_writes())
+ cnt.count &= (1ull << pmu.gp_counter_width) - 1;
}
if (i % 2)
--
2.34.1
^ permalink raw reply related [flat|nested] 16+ messages in thread* Re: [kvm-unit-tests patch v3 3/8] x86/pmu: Fix incorrect masking of fixed counters
2025-09-03 6:45 ` [kvm-unit-tests patch v3 3/8] x86/pmu: Fix incorrect masking of fixed counters Dapeng Mi
@ 2025-11-20 22:28 ` Sean Christopherson
2025-11-21 1:25 ` Mi, Dapeng
0 siblings, 1 reply; 16+ messages in thread
From: Sean Christopherson @ 2025-11-20 22:28 UTC (permalink / raw)
To: Dapeng Mi
Cc: Paolo Bonzini, kvm, linux-kernel, Jim Mattson, Mingwei Zhang,
Zide Chen, Das Sandipan, Shukla Manali, Xiaoyao Li, Dapeng Mi,
dongsheng, Yi Lai
On Wed, Sep 03, 2025, Dapeng Mi wrote:
> From: dongsheng <dongsheng.x.zhang@intel.com>
>
> The current implementation mistakenly limits the width of fixed counters
> to the width of GP counters. Corrects the logic to ensure fixed counters
> are properly masked according to their own width.
>
> Opportunistically refine the GP counter bitwidth processing code.
>
> Signed-off-by: dongsheng <dongsheng.x.zhang@intel.com>
> Co-developed-by: Dapeng Mi <dapeng1.mi@linux.intel.com>
> Signed-off-by: Dapeng Mi <dapeng1.mi@linux.intel.com>
> Tested-by: Yi Lai <yi1.lai@intel.com>
> ---
> x86/pmu.c | 8 +++-----
> 1 file changed, 3 insertions(+), 5 deletions(-)
>
> diff --git a/x86/pmu.c b/x86/pmu.c
> index 04946d10..44c728a5 100644
> --- a/x86/pmu.c
> +++ b/x86/pmu.c
> @@ -556,18 +556,16 @@ static void check_counter_overflow(void)
> int idx;
>
> cnt.count = overflow_preset;
> - if (pmu_use_full_writes())
> - cnt.count &= (1ull << pmu.gp_counter_width) - 1;
> -
> if (i == pmu.nr_gp_counters) {
> if (!pmu.is_intel)
> break;
>
> cnt.ctr = fixed_events[0].unit_sel;
> - cnt.count = measure_for_overflow(&cnt);
Per commit 7ec3b67a ("x86/pmu: Reset the expected count of the fixed counter 0
when i386"), re-measuring for the fixed counter is necessary when running a 32-bit
guests. I didn't see failures (spotted this by inspection), but I don't see any
point in making this change without good reason.
> - cnt.count &= (1ull << pmu.gp_counter_width) - 1;
> + cnt.count &= (1ull << pmu.fixed_counter_width) - 1;
> } else {
> cnt.ctr = MSR_GP_COUNTERx(i);
> + if (pmu_use_full_writes())
> + cnt.count &= (1ull << pmu.gp_counter_width) - 1;
> }
>
> if (i % 2)
> --
> 2.34.1
>
^ permalink raw reply [flat|nested] 16+ messages in thread* Re: [kvm-unit-tests patch v3 3/8] x86/pmu: Fix incorrect masking of fixed counters
2025-11-20 22:28 ` Sean Christopherson
@ 2025-11-21 1:25 ` Mi, Dapeng
0 siblings, 0 replies; 16+ messages in thread
From: Mi, Dapeng @ 2025-11-21 1:25 UTC (permalink / raw)
To: Sean Christopherson
Cc: Paolo Bonzini, kvm, linux-kernel, Jim Mattson, Mingwei Zhang,
Zide Chen, Das Sandipan, Shukla Manali, Xiaoyao Li, Dapeng Mi,
dongsheng, Yi Lai
On 11/21/2025 6:28 AM, Sean Christopherson wrote:
> On Wed, Sep 03, 2025, Dapeng Mi wrote:
>> From: dongsheng <dongsheng.x.zhang@intel.com>
>>
>> The current implementation mistakenly limits the width of fixed counters
>> to the width of GP counters. Corrects the logic to ensure fixed counters
>> are properly masked according to their own width.
>>
>> Opportunistically refine the GP counter bitwidth processing code.
>>
>> Signed-off-by: dongsheng <dongsheng.x.zhang@intel.com>
>> Co-developed-by: Dapeng Mi <dapeng1.mi@linux.intel.com>
>> Signed-off-by: Dapeng Mi <dapeng1.mi@linux.intel.com>
>> Tested-by: Yi Lai <yi1.lai@intel.com>
>> ---
>> x86/pmu.c | 8 +++-----
>> 1 file changed, 3 insertions(+), 5 deletions(-)
>>
>> diff --git a/x86/pmu.c b/x86/pmu.c
>> index 04946d10..44c728a5 100644
>> --- a/x86/pmu.c
>> +++ b/x86/pmu.c
>> @@ -556,18 +556,16 @@ static void check_counter_overflow(void)
>> int idx;
>>
>> cnt.count = overflow_preset;
>> - if (pmu_use_full_writes())
>> - cnt.count &= (1ull << pmu.gp_counter_width) - 1;
>> -
>> if (i == pmu.nr_gp_counters) {
>> if (!pmu.is_intel)
>> break;
>>
>> cnt.ctr = fixed_events[0].unit_sel;
>> - cnt.count = (&cnt);
> Per commit 7ec3b67a ("x86/pmu: Reset the expected count of the fixed counter 0
> when i386"), re-measuring for the fixed counter is necessary when running a 32-bit
> guests. I didn't see failures (spotted this by inspection), but I don't see any
> point in making this change without good reason.
Thanks. I didn't realized that the 2nd measure_for_overflow() is intended
to add ...
>
>> - cnt.count &= (1ull << pmu.gp_counter_width) - 1;
>> + cnt.count &= (1ull << pmu.fixed_counter_width) - 1;
>> } else {
>> cnt.ctr = MSR_GP_COUNTERx(i);
>> + if (pmu_use_full_writes())
>> + cnt.count &= (1ull << pmu.gp_counter_width) - 1;
>> }
>>
>> if (i % 2)
>> --
>> 2.34.1
>>
^ permalink raw reply [flat|nested] 16+ messages in thread
* [kvm-unit-tests patch v3 4/8] x86/pmu: Handle instruction overcount issue in overflow test
2025-09-03 6:45 [kvm-unit-tests patch v3 0/8] Fix pmu test errors on GNR/SRF/CWF Dapeng Mi
` (2 preceding siblings ...)
2025-09-03 6:45 ` [kvm-unit-tests patch v3 3/8] x86/pmu: Fix incorrect masking of fixed counters Dapeng Mi
@ 2025-09-03 6:45 ` Dapeng Mi
2025-09-03 6:45 ` [kvm-unit-tests patch v3 5/8] x86/pmu: Relax precise count check for emulated instructions tests Dapeng Mi
` (4 subsequent siblings)
8 siblings, 0 replies; 16+ messages in thread
From: Dapeng Mi @ 2025-09-03 6:45 UTC (permalink / raw)
To: Sean Christopherson, Paolo Bonzini
Cc: kvm, linux-kernel, Jim Mattson, Mingwei Zhang, Zide Chen,
Das Sandipan, Shukla Manali, Xiaoyao Li, Dapeng Mi, dongsheng,
Dapeng Mi, Yi Lai
From: dongsheng <dongsheng.x.zhang@intel.com>
During the execution of __measure(), VM exits (e.g., due to
WRMSR/EXTERNAL_INTERRUPT) may occur. On systems affected by the
instruction overcount issue, each VM-Exit/VM-Entry can erroneously
increment the instruction count by one, leading to false failures in
overflow tests.
To address this, the patch introduces a range-based validation in place
of precise instruction count checks. Additionally, overflow_preset is
now statically set to 1 - LOOP_INSNS, rather than being dynamically
determined via measure_for_overflow().
These changes ensure consistent and predictable behavior aligned with the
intended loop instruction count, while avoiding modifications to the
subsequent status and status-clear testing logic.
The chosen validation range is empirically derived to maintain test
reliability across hardware variations.
Signed-off-by: dongsheng <dongsheng.x.zhang@intel.com>
Signed-off-by: Dapeng Mi <dapeng1.mi@linux.intel.com>
Tested-by: Yi Lai <yi1.lai@intel.com>
---
x86/pmu.c | 23 +++++++++++++++++++++--
1 file changed, 21 insertions(+), 2 deletions(-)
diff --git a/x86/pmu.c b/x86/pmu.c
index 44c728a5..c54c0988 100644
--- a/x86/pmu.c
+++ b/x86/pmu.c
@@ -518,6 +518,21 @@ static void check_counters_many(void)
static uint64_t measure_for_overflow(pmu_counter_t *cnt)
{
+ /*
+ * During the execution of __measure(), VM exits (e.g., due to
+ * WRMSR/EXTERNAL_INTERRUPT) may occur. On systems affected by the
+ * instruction overcount issue, each VM-Exit/VM-Entry can erroneously
+ * increment the instruction count by one, leading to false failures
+ * in overflow tests.
+ *
+ * To mitigate this, if the overcount issue is detected, we hardcode
+ * the overflow preset to (1 - LOOP_INSNS) instead of calculating it
+ * dynamically. This ensures that an overflow will reliably occur,
+ * regardless of any overcounting caused by VM exits.
+ */
+ if (intel_inst_overcount_flags & INST_RETIRED_OVERCOUNT)
+ return 1 - LOOP_INSNS;
+
__measure(cnt, 0);
/*
* To generate overflow, i.e. roll over to '0', the initial count just
@@ -574,8 +589,12 @@ static void check_counter_overflow(void)
cnt.config &= ~EVNTSEL_INT;
idx = event_to_global_idx(&cnt);
__measure(&cnt, cnt.count);
- if (pmu.is_intel)
- report(cnt.count == 1, "cntr-%d", i);
+ if (pmu.is_intel) {
+ if (intel_inst_overcount_flags & INST_RETIRED_OVERCOUNT)
+ report(cnt.count < 14, "cntr-%d", i);
+ else
+ report(cnt.count == 1, "cntr-%d", i);
+ }
else
report(cnt.count == 0xffffffffffff || cnt.count < 7, "cntr-%d", i);
--
2.34.1
^ permalink raw reply related [flat|nested] 16+ messages in thread* [kvm-unit-tests patch v3 5/8] x86/pmu: Relax precise count check for emulated instructions tests
2025-09-03 6:45 [kvm-unit-tests patch v3 0/8] Fix pmu test errors on GNR/SRF/CWF Dapeng Mi
` (3 preceding siblings ...)
2025-09-03 6:45 ` [kvm-unit-tests patch v3 4/8] x86/pmu: Handle instruction overcount issue in overflow test Dapeng Mi
@ 2025-09-03 6:45 ` Dapeng Mi
2025-11-20 22:29 ` Sean Christopherson
2025-09-03 6:45 ` [kvm-unit-tests patch v3 6/8] x86/pmu: Expand "llc references" upper limit for broader compatibility Dapeng Mi
` (3 subsequent siblings)
8 siblings, 1 reply; 16+ messages in thread
From: Dapeng Mi @ 2025-09-03 6:45 UTC (permalink / raw)
To: Sean Christopherson, Paolo Bonzini
Cc: kvm, linux-kernel, Jim Mattson, Mingwei Zhang, Zide Chen,
Das Sandipan, Shukla Manali, Xiaoyao Li, Dapeng Mi, Dapeng Mi
Relax precise count check for emulated instructions tests on these
platforms with HW overcount issues.
Signed-off-by: Dapeng Mi <dapeng1.mi@linux.intel.com>
---
x86/pmu.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/x86/pmu.c b/x86/pmu.c
index c54c0988..6bf6eee3 100644
--- a/x86/pmu.c
+++ b/x86/pmu.c
@@ -790,7 +790,7 @@ static void check_emulated_instr(void)
// Check that the end count - start count is at least the expected
// number of instructions and branches.
- if (this_cpu_has_perf_global_ctrl()) {
+ if (this_cpu_has_perf_global_ctrl() && !intel_inst_overcount_flags) {
report(instr_cnt.count - instr_start == KVM_FEP_INSNS,
"instruction count");
report(brnch_cnt.count - brnch_start == KVM_FEP_BRANCHES,
--
2.34.1
^ permalink raw reply related [flat|nested] 16+ messages in thread* Re: [kvm-unit-tests patch v3 5/8] x86/pmu: Relax precise count check for emulated instructions tests
2025-09-03 6:45 ` [kvm-unit-tests patch v3 5/8] x86/pmu: Relax precise count check for emulated instructions tests Dapeng Mi
@ 2025-11-20 22:29 ` Sean Christopherson
2025-11-21 0:53 ` Mi, Dapeng
0 siblings, 1 reply; 16+ messages in thread
From: Sean Christopherson @ 2025-11-20 22:29 UTC (permalink / raw)
To: Dapeng Mi
Cc: Paolo Bonzini, kvm, linux-kernel, Jim Mattson, Mingwei Zhang,
Zide Chen, Das Sandipan, Shukla Manali, Xiaoyao Li, Dapeng Mi
On Wed, Sep 03, 2025, Dapeng Mi wrote:
> Relax precise count check for emulated instructions tests on these
> platforms with HW overcount issues.
>
> Signed-off-by: Dapeng Mi <dapeng1.mi@linux.intel.com>
> ---
> x86/pmu.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/x86/pmu.c b/x86/pmu.c
> index c54c0988..6bf6eee3 100644
> --- a/x86/pmu.c
> +++ b/x86/pmu.c
> @@ -790,7 +790,7 @@ static void check_emulated_instr(void)
>
> // Check that the end count - start count is at least the expected
> // number of instructions and branches.
> - if (this_cpu_has_perf_global_ctrl()) {
> + if (this_cpu_has_perf_global_ctrl() && !intel_inst_overcount_flags) {
This skips precise checking if _either_ errata is present. IIUC, we can still do
a precise check for branches retired on Clearwater Forest, but not for instructions
retired.
> report(instr_cnt.count - instr_start == KVM_FEP_INSNS,
> "instruction count");
> report(brnch_cnt.count - brnch_start == KVM_FEP_BRANCHES,
> --
> 2.34.1
>
^ permalink raw reply [flat|nested] 16+ messages in thread* Re: [kvm-unit-tests patch v3 5/8] x86/pmu: Relax precise count check for emulated instructions tests
2025-11-20 22:29 ` Sean Christopherson
@ 2025-11-21 0:53 ` Mi, Dapeng
0 siblings, 0 replies; 16+ messages in thread
From: Mi, Dapeng @ 2025-11-21 0:53 UTC (permalink / raw)
To: Sean Christopherson
Cc: Paolo Bonzini, kvm, linux-kernel, Jim Mattson, Mingwei Zhang,
Zide Chen, Das Sandipan, Shukla Manali, Xiaoyao Li, Dapeng Mi
On 11/21/2025 6:29 AM, Sean Christopherson wrote:
> On Wed, Sep 03, 2025, Dapeng Mi wrote:
>> Relax precise count check for emulated instructions tests on these
>> platforms with HW overcount issues.
>>
>> Signed-off-by: Dapeng Mi <dapeng1.mi@linux.intel.com>
>> ---
>> x86/pmu.c | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/x86/pmu.c b/x86/pmu.c
>> index c54c0988..6bf6eee3 100644
>> --- a/x86/pmu.c
>> +++ b/x86/pmu.c
>> @@ -790,7 +790,7 @@ static void check_emulated_instr(void)
>>
>> // Check that the end count - start count is at least the expected
>> // number of instructions and branches.
>> - if (this_cpu_has_perf_global_ctrl()) {
>> + if (this_cpu_has_perf_global_ctrl() && !intel_inst_overcount_flags) {
> This skips precise checking if _either_ errata is present. IIUC, we can still do
> a precise check for branches retired on Clearwater Forest, but not for instructions
> retired.
Yes, this is correct.
>
>> report(instr_cnt.count - instr_start == KVM_FEP_INSNS,
>> "instruction count");
>> report(brnch_cnt.count - brnch_start == KVM_FEP_BRANCHES,
>> --
>> 2.34.1
>>
^ permalink raw reply [flat|nested] 16+ messages in thread
* [kvm-unit-tests patch v3 6/8] x86/pmu: Expand "llc references" upper limit for broader compatibility
2025-09-03 6:45 [kvm-unit-tests patch v3 0/8] Fix pmu test errors on GNR/SRF/CWF Dapeng Mi
` (4 preceding siblings ...)
2025-09-03 6:45 ` [kvm-unit-tests patch v3 5/8] x86/pmu: Relax precise count check for emulated instructions tests Dapeng Mi
@ 2025-09-03 6:45 ` Dapeng Mi
2025-09-03 6:46 ` [kvm-unit-tests patch v3 7/8] x86: pmu_pebs: Remove abundant data_cfg_match calculation Dapeng Mi
` (2 subsequent siblings)
8 siblings, 0 replies; 16+ messages in thread
From: Dapeng Mi @ 2025-09-03 6:45 UTC (permalink / raw)
To: Sean Christopherson, Paolo Bonzini
Cc: kvm, linux-kernel, Jim Mattson, Mingwei Zhang, Zide Chen,
Das Sandipan, Shukla Manali, Xiaoyao Li, Dapeng Mi, dongsheng,
Dapeng Mi, Yi Lai
From: dongsheng <dongsheng.x.zhang@intel.com>
Increase the upper limit of the "llc references" test to accommodate
results observed on additional Intel CPU models, including CWF and
SRF.
These CPUs exhibited higher reference counts that previously caused
the test to fail.
Signed-off-by: dongsheng <dongsheng.x.zhang@intel.com>
Signed-off-by: Dapeng Mi <dapeng1.mi@linux.intel.com>
Tested-by: Yi Lai <yi1.lai@intel.com>
---
x86/pmu.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/x86/pmu.c b/x86/pmu.c
index 6bf6eee3..49d25f68 100644
--- a/x86/pmu.c
+++ b/x86/pmu.c
@@ -116,7 +116,7 @@ struct pmu_event {
{"core cycles", 0x003c, 1*N, 50*N},
{"instructions", 0x00c0, 10*N, 10.2*N},
{"ref cycles", 0x013c, 1*N, 30*N},
- {"llc references", 0x4f2e, 1, 2*N},
+ {"llc references", 0x4f2e, 1, 2.5*N},
{"llc misses", 0x412e, 1, 1*N},
{"branches", 0x00c4, 1*N, 1.1*N},
{"branch misses", 0x00c5, 1, 0.1*N},
--
2.34.1
^ permalink raw reply related [flat|nested] 16+ messages in thread* [kvm-unit-tests patch v3 7/8] x86: pmu_pebs: Remove abundant data_cfg_match calculation
2025-09-03 6:45 [kvm-unit-tests patch v3 0/8] Fix pmu test errors on GNR/SRF/CWF Dapeng Mi
` (5 preceding siblings ...)
2025-09-03 6:45 ` [kvm-unit-tests patch v3 6/8] x86/pmu: Expand "llc references" upper limit for broader compatibility Dapeng Mi
@ 2025-09-03 6:46 ` Dapeng Mi
2025-09-03 6:46 ` [kvm-unit-tests patch v3 8/8] x86: pmu_pebs: Support to validate timed PEBS record on GNR/SRF Dapeng Mi
2025-11-20 22:30 ` [kvm-unit-tests patch v3 0/8] Fix pmu test errors on GNR/SRF/CWF Sean Christopherson
8 siblings, 0 replies; 16+ messages in thread
From: Dapeng Mi @ 2025-09-03 6:46 UTC (permalink / raw)
To: Sean Christopherson, Paolo Bonzini
Cc: kvm, linux-kernel, Jim Mattson, Mingwei Zhang, Zide Chen,
Das Sandipan, Shukla Manali, Xiaoyao Li, Dapeng Mi, Dapeng Mi,
Yi Lai
Remove abundant data_cfg_match calculation.
Signed-off-by: Dapeng Mi <dapeng1.mi@linux.intel.com>
Tested-by: Yi Lai <yi1.lai@intel.com>
---
x86/pmu_pebs.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/x86/pmu_pebs.c b/x86/pmu_pebs.c
index 6e73fc34..2848cc1e 100644
--- a/x86/pmu_pebs.c
+++ b/x86/pmu_pebs.c
@@ -296,7 +296,6 @@ static void check_pebs_records(u64 bitmask, u64 pebs_data_cfg, bool use_adaptive
pebs_record_size = pebs_rec->format_size >> RECORD_SIZE_OFFSET;
pebs_idx_match = pebs_rec->applicable_counters & bitmask;
pebs_size_match = pebs_record_size == get_pebs_record_size(pebs_data_cfg, use_adaptive);
- data_cfg_match = (pebs_rec->format_size & GENMASK_ULL(47, 0)) == pebs_data_cfg;
data_cfg_match = (pebs_rec->format_size & GENMASK_ULL(47, 0)) ==
(use_adaptive ? pebs_data_cfg : 0);
expected = pebs_idx_match && pebs_size_match && data_cfg_match;
--
2.34.1
^ permalink raw reply related [flat|nested] 16+ messages in thread* [kvm-unit-tests patch v3 8/8] x86: pmu_pebs: Support to validate timed PEBS record on GNR/SRF
2025-09-03 6:45 [kvm-unit-tests patch v3 0/8] Fix pmu test errors on GNR/SRF/CWF Dapeng Mi
` (6 preceding siblings ...)
2025-09-03 6:46 ` [kvm-unit-tests patch v3 7/8] x86: pmu_pebs: Remove abundant data_cfg_match calculation Dapeng Mi
@ 2025-09-03 6:46 ` Dapeng Mi
2025-11-20 22:30 ` [kvm-unit-tests patch v3 0/8] Fix pmu test errors on GNR/SRF/CWF Sean Christopherson
8 siblings, 0 replies; 16+ messages in thread
From: Dapeng Mi @ 2025-09-03 6:46 UTC (permalink / raw)
To: Sean Christopherson, Paolo Bonzini
Cc: kvm, linux-kernel, Jim Mattson, Mingwei Zhang, Zide Chen,
Das Sandipan, Shukla Manali, Xiaoyao Li, Dapeng Mi, Dapeng Mi,
Kan Liang, Yi Lai
On Intel GNR/SRF platform, timed PEBS is introduced. Timed PEBS adds
a new "retired latency" field in basic info group to show the timing
info. IA32_PERF_CAPABILITIES.PEBS_TIMING_INFO[bit 17] is introduced to
indicate whether timed PEBS is supported.
After introducing timed PEBS, the PEBS record format field shrinks to
bits[31:0] and the bits[47:32] is used to record retired latency.
Thus shrink the record format to bits[31:0] accordingly and avoid the
retired latency field is recognized a part of record format to compare
and cause failure on GNR/SRF.
Please find detailed information about timed PEBS in section 8.4.1
"Timed Processor Event Based Sampling" of "Intel Architecture
Instruction Set Extensions and Future Features".
Reviewed-by: Kan Liang <kan.liang@linux.intel.com>
Signed-off-by: Dapeng Mi <dapeng1.mi@linux.intel.com>
Tested-by: Yi Lai <yi1.lai@intel.com>
---
lib/x86/pmu.h | 6 ++++++
x86/pmu_pebs.c | 8 +++++---
2 files changed, 11 insertions(+), 3 deletions(-)
diff --git a/lib/x86/pmu.h b/lib/x86/pmu.h
index c7dc68c1..86a7a05f 100644
--- a/lib/x86/pmu.h
+++ b/lib/x86/pmu.h
@@ -20,6 +20,7 @@
#define PMU_CAP_LBR_FMT 0x3f
#define PMU_CAP_FW_WRITES (1ULL << 13)
#define PMU_CAP_PEBS_BASELINE (1ULL << 14)
+#define PMU_CAP_PEBS_TIMING_INFO (1ULL << 17)
#define PERF_CAP_PEBS_FORMAT 0xf00
#define EVNSEL_EVENT_SHIFT 0
@@ -188,4 +189,9 @@ static inline bool pmu_has_pebs_baseline(void)
return pmu.perf_cap & PMU_CAP_PEBS_BASELINE;
}
+static inline bool pmu_has_pebs_timing_info(void)
+{
+ return pmu.perf_cap & PMU_CAP_PEBS_TIMING_INFO;
+}
+
#endif /* _X86_PMU_H_ */
diff --git a/x86/pmu_pebs.c b/x86/pmu_pebs.c
index 2848cc1e..bc37e8e3 100644
--- a/x86/pmu_pebs.c
+++ b/x86/pmu_pebs.c
@@ -277,6 +277,7 @@ static void check_pebs_records(u64 bitmask, u64 pebs_data_cfg, bool use_adaptive
unsigned int count = 0;
bool expected, pebs_idx_match, pebs_size_match, data_cfg_match;
void *cur_record;
+ u64 format_mask;
expected = (ds->pebs_index == ds->pebs_buffer_base) && !pebs_rec->format_size;
if (!(rdmsr(MSR_CORE_PERF_GLOBAL_STATUS) & GLOBAL_STATUS_BUFFER_OVF)) {
@@ -289,6 +290,8 @@ static void check_pebs_records(u64 bitmask, u64 pebs_data_cfg, bool use_adaptive
return;
}
+ /* Record format shrinks to bits[31:0] after timed PEBS is introduced. */
+ format_mask = pmu_has_pebs_timing_info() ? GENMASK_ULL(31, 0) : GENMASK_ULL(47, 0);
expected = ds->pebs_index >= ds->pebs_interrupt_threshold;
cur_record = (void *)pebs_buffer;
do {
@@ -296,8 +299,7 @@ static void check_pebs_records(u64 bitmask, u64 pebs_data_cfg, bool use_adaptive
pebs_record_size = pebs_rec->format_size >> RECORD_SIZE_OFFSET;
pebs_idx_match = pebs_rec->applicable_counters & bitmask;
pebs_size_match = pebs_record_size == get_pebs_record_size(pebs_data_cfg, use_adaptive);
- data_cfg_match = (pebs_rec->format_size & GENMASK_ULL(47, 0)) ==
- (use_adaptive ? pebs_data_cfg : 0);
+ data_cfg_match = (pebs_rec->format_size & format_mask) == (use_adaptive ? pebs_data_cfg : 0);
expected = pebs_idx_match && pebs_size_match && data_cfg_match;
report(expected,
"PEBS record (written seq %d) is verified (including size, counters and cfg).", count);
@@ -327,7 +329,7 @@ static void check_pebs_records(u64 bitmask, u64 pebs_data_cfg, bool use_adaptive
pebs_record_size, get_pebs_record_size(pebs_data_cfg, use_adaptive));
if (!data_cfg_match)
printf("FAIL: The pebs_data_cfg (0x%lx) doesn't match with the effective MSR_PEBS_DATA_CFG (0x%lx).\n",
- pebs_rec->format_size & 0xffffffffffff, use_adaptive ? pebs_data_cfg : 0);
+ pebs_rec->format_size & format_mask, use_adaptive ? pebs_data_cfg : 0);
}
}
--
2.34.1
^ permalink raw reply related [flat|nested] 16+ messages in thread* Re: [kvm-unit-tests patch v3 0/8] Fix pmu test errors on GNR/SRF/CWF
2025-09-03 6:45 [kvm-unit-tests patch v3 0/8] Fix pmu test errors on GNR/SRF/CWF Dapeng Mi
` (7 preceding siblings ...)
2025-09-03 6:46 ` [kvm-unit-tests patch v3 8/8] x86: pmu_pebs: Support to validate timed PEBS record on GNR/SRF Dapeng Mi
@ 2025-11-20 22:30 ` Sean Christopherson
8 siblings, 0 replies; 16+ messages in thread
From: Sean Christopherson @ 2025-11-20 22:30 UTC (permalink / raw)
To: Dapeng Mi
Cc: Paolo Bonzini, kvm, linux-kernel, Jim Mattson, Mingwei Zhang,
Zide Chen, Das Sandipan, Shukla Manali, Xiaoyao Li, Dapeng Mi
On Wed, Sep 03, 2025, Dapeng Mi wrote:
> Dapeng Mi (3):
> x86/pmu: Relax precise count check for emulated instructions tests
> x86: pmu_pebs: Remove abundant data_cfg_match calculation
> x86: pmu_pebs: Support to validate timed PEBS record on GNR/SRF
>
> dongsheng (5):
> x86/pmu: Add helper to detect Intel overcount issues
> x86/pmu: Relax precise count validation for Intel overcounted
> platforms
> x86/pmu: Fix incorrect masking of fixed counters
> x86/pmu: Handle instruction overcount issue in overflow test
> x86/pmu: Expand "llc references" upper limit for broader compatibility
>
> lib/x86/pmu.h | 6 +++
> lib/x86/processor.h | 27 +++++++++++++
> x86/pmu.c | 95 ++++++++++++++++++++++++++++++++++++++-------
> x86/pmu_pebs.c | 9 +++--
> 4 files changed, 120 insertions(+), 17 deletions(-)
Some minor issues, but otherwise looks good. I'll take care of all the issues
(though I'll still post a v4 so that there's a paper trail for what I'm applying).
^ permalink raw reply [flat|nested] 16+ messages in thread