* [LTP] [PATCH v10] high_freq_hwp_cap_cppc.c: new test
@ 2026-05-05 9:54 Piotr Kubaj
2026-05-05 17:54 ` [LTP] " linuxtestproject.agent
2026-05-06 12:38 ` [LTP] [PATCH v10] " Andrea Cervesato via ltp
0 siblings, 2 replies; 3+ messages in thread
From: Piotr Kubaj @ 2026-05-05 9:54 UTC (permalink / raw)
To: ltp; +Cc: helena.anna.dubel, tomasz.ossowski, rafael.j.wysocki,
daniel.niestepski
Verify for all online logical CPUs that their highest performance value are
the same for HWP Capability MSR 0x771 and CPPC sysfs file.
On HWP-capable x86 platforms the acpi_cppc/highest_perf sysfs attribute is
expected to reflect the same highest-performance value that firmware
programs into the HWP Capabilities MSR (0x771, bits 7:0). A mismatch
between the two interfaces indicates a kernel regression in how CPPC
values are exposed to userspace, and would break tools (e.g. cpupower,
intel_pstate tuning scripts) that rely on the sysfs interface to make
frequency-scaling decisions.
Signed-off-by: Piotr Kubaj <piotr.kubaj@intel.com>
---
Addressed both points raised in a review:
1. motivation for the test.
2. fd leak.
runtest/power_management_tests | 1 +
testcases/kernel/power_management/.gitignore | 1 +
.../power_management/high_freq_hwp_cap_cppc.c | 105 ++++++++++++++++++
3 files changed, 107 insertions(+)
create mode 100644 testcases/kernel/power_management/.gitignore
create mode 100644 testcases/kernel/power_management/high_freq_hwp_cap_cppc.c
diff --git a/runtest/power_management_tests b/runtest/power_management_tests
index b670da6ec..4da57ee72 100644
--- a/runtest/power_management_tests
+++ b/runtest/power_management_tests
@@ -1,4 +1,5 @@
#POWER_MANAGEMENT
+high_freq_hwp_cap_cppc high_freq_hwp_cap_cppc
runpwtests03 runpwtests03.sh
runpwtests04 runpwtests04.sh
runpwtests06 runpwtests06.sh
diff --git a/testcases/kernel/power_management/.gitignore b/testcases/kernel/power_management/.gitignore
new file mode 100644
index 000000000..03f0c83e4
--- /dev/null
+++ b/testcases/kernel/power_management/.gitignore
@@ -0,0 +1 @@
+high_freq_hwp_cap_cppc
diff --git a/testcases/kernel/power_management/high_freq_hwp_cap_cppc.c b/testcases/kernel/power_management/high_freq_hwp_cap_cppc.c
new file mode 100644
index 000000000..d3c697875
--- /dev/null
+++ b/testcases/kernel/power_management/high_freq_hwp_cap_cppc.c
@@ -0,0 +1,105 @@
+// SPDX-License-Identifier: GPL-2.0-or-later
+/*
+ * Copyright (C) 2026 Piotr Kubaj <piotr.kubaj@intel.com>
+ */
+
+/*\
+ * Verify for all online logical CPUs that their highest performance value are
+ * the same for HWP Capability MSR 0x771 and CPPC sysfs file.
+ *
+ * On HWP-capable x86 platforms the acpi_cppc/highest_perf sysfs attribute is
+ * expected to reflect the same highest-performance value that firmware
+ * programs into the HWP Capabilities MSR (0x771, bits 7:0). A mismatch
+ * between the two interfaces indicates a kernel regression in how CPPC
+ * values are exposed to userspace, and would break tools (e.g. cpupower,
+ * intel_pstate tuning scripts) that rely on the sysfs interface to make
+ * frequency-scaling decisions.
+ */
+
+#include "tst_test.h"
+#include "tst_safe_prw.h"
+
+#define MSR_HWP_CAPABILITIES 0x771
+#define HIGHEST_PERF_MASK 0xFF
+
+static int nproc;
+static int fd = -1;
+
+static void setup(void)
+{
+ if (access("/dev/cpu/0/msr", F_OK) == -1)
+ tst_brk(TCONF | TERRNO, "msr driver not loaded");
+
+ if (access("/sys/devices/system/cpu/cpu0/acpi_cppc/highest_perf", F_OK) == -1)
+ tst_brk(TCONF | TERRNO, "CPPC sysfs not available");
+
+ nproc = tst_ncpus_conf();
+}
+
+static void cleanup(void)
+{
+ if (fd != -1)
+ SAFE_CLOSE(fd);
+}
+
+static void run(void)
+{
+ bool status = true;
+ char path[PATH_MAX];
+
+ for (int i = 0; i < nproc; i++) {
+ int online = 1;
+ unsigned long long msr_highest_perf = 0, sysfs_highest_perf = 0;
+
+ if (i) {
+ snprintf(path, sizeof(path), "/sys/devices/system/cpu/cpu%d/online", i);
+ SAFE_FILE_SCANF(path, "%d", &online);
+ }
+
+ if (!online) {
+ tst_res(TINFO, "CPU%d offline, skipping", i);
+ continue;
+ }
+
+ snprintf(path, sizeof(path), "/sys/devices/system/cpu/cpu%d/acpi_cppc/highest_perf", i);
+ SAFE_FILE_SCANF(path, "%llu", &sysfs_highest_perf);
+ tst_res(TDEBUG, "%s: %llu", path, sysfs_highest_perf);
+
+ snprintf(path, sizeof(path), "/dev/cpu/%d/msr", i);
+ fd = SAFE_OPEN(path, O_RDONLY);
+
+ SAFE_PREAD(1, fd, &msr_highest_perf, sizeof(msr_highest_perf), MSR_HWP_CAPABILITIES);
+ SAFE_CLOSE(fd);
+ fd = -1;
+ msr_highest_perf &= HIGHEST_PERF_MASK;
+ tst_res(TDEBUG, "%s: %llu", path, msr_highest_perf);
+
+ if (msr_highest_perf != sysfs_highest_perf) {
+ tst_res(TINFO, "cpu%d: sysfs=%llu MSR=%llu",
+ i, sysfs_highest_perf, msr_highest_perf);
+ status = false;
+ }
+ }
+
+ if (status)
+ tst_res(TPASS, "Sysfs and MSR values are equal");
+ else
+ tst_res(TFAIL, "Highest performance values differ between sysfs and MSR");
+}
+
+static struct tst_test test = {
+ .needs_kconfigs = (const char *const []) {
+ "CONFIG_ACPI_CPPC_LIB",
+ "CONFIG_X86_MSR",
+ NULL
+ },
+ .needs_root = 1,
+ .setup = setup,
+ .cleanup = cleanup,
+ .supported_archs = (const char *const []) {
+ "x86",
+ "x86_64",
+ NULL
+ },
+ .test_all = run
+};
--
2.47.3
---------------------------------------------------------------------
Intel Technology Poland sp. z o.o.
ul. Slowackiego 173 | 80-298 Gdansk | Sad Rejonowy Gdansk Polnoc | VII Wydzial Gospodarczy Krajowego Rejestru Sadowego - KRS 101882 | NIP 957-07-52-316 | Kapital zakladowy 200.000 PLN.
Spolka oswiadcza, ze posiada status duzego przedsiebiorcy w rozumieniu ustawy z dnia 8 marca 2013 r. o przeciwdzialaniu nadmiernym opoznieniom w transakcjach handlowych.
Ta wiadomosc wraz z zalacznikami jest przeznaczona dla okreslonego adresata i moze zawierac informacje poufne. W razie przypadkowego otrzymania tej wiadomosci, prosimy o powiadomienie nadawcy oraz trwale jej usuniecie; jakiekolwiek przegladanie lub rozpowszechnianie jest zabronione.
This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). If you are not the intended recipient, please contact the sender and delete all copies; any review or distribution by others is strictly prohibited.
--
Mailing list info: https://lists.linux.it/listinfo/ltp
^ permalink raw reply related [flat|nested] 3+ messages in thread* Re: [LTP] high_freq_hwp_cap_cppc.c: new test
2026-05-05 9:54 [LTP] [PATCH v10] high_freq_hwp_cap_cppc.c: new test Piotr Kubaj
@ 2026-05-05 17:54 ` linuxtestproject.agent
2026-05-06 12:38 ` [LTP] [PATCH v10] " Andrea Cervesato via ltp
1 sibling, 0 replies; 3+ messages in thread
From: linuxtestproject.agent @ 2026-05-05 17:54 UTC (permalink / raw)
To: Piotr Kubaj; +Cc: ltp, LTP AI Reviewer
Hi Piotr,
On Tue, 5 May 2026, Piotr Kubaj wrote:
> high_freq_hwp_cap_cppc.c: new test
Reviewed-by: LTP AI Reviewer <ltp-ai@noreply.github.com>
---
Note:
Our agent completed the review of the patch.
The agent can sometimes produce false positives although often its
findings are genuine. If you find issues with the review, please
comment this email or ignore the suggestions.
Regards,
LTP AI Reviewer
--
Mailing list info: https://lists.linux.it/listinfo/ltp
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: [LTP] [PATCH v10] high_freq_hwp_cap_cppc.c: new test
2026-05-05 9:54 [LTP] [PATCH v10] high_freq_hwp_cap_cppc.c: new test Piotr Kubaj
2026-05-05 17:54 ` [LTP] " linuxtestproject.agent
@ 2026-05-06 12:38 ` Andrea Cervesato via ltp
1 sibling, 0 replies; 3+ messages in thread
From: Andrea Cervesato via ltp @ 2026-05-06 12:38 UTC (permalink / raw)
To: Piotr Kubaj
Cc: daniel.niestepski, tomasz.ossowski, helena.anna.dubel,
rafael.j.wysocki, ltp
Hi Piotr,
> + SAFE_PREAD(1, fd, &msr_highest_perf, sizeof(msr_highest_perf), MSR_HWP_CAPABILITIES);
> + SAFE_CLOSE(fd);
> + fd = -1;
This is not needed because it's done by SAFE_CLOSE() already.
> + msr_highest_perf &= HIGHEST_PERF_MASK;
> + tst_res(TDEBUG, "%s: %llu", path, msr_highest_perf);
> +
> + if (msr_highest_perf != sysfs_highest_perf) {
> + tst_res(TINFO, "cpu%d: sysfs=%llu MSR=%llu",
> + i, sysfs_highest_perf, msr_highest_perf);
> + status = false;
After this we should return, otherwise we keep cycling and next status
value might change again. I would just add here the TFAIL and return at
this point, so status variable goes away.
Unless, we want to track _all_ CPUs and then (at the end) print the
result. In this case, you need an array of int, assiging 1 in case of
error and 0 in case of success.
And the ending check, after the loop, will print the status of all
CPUs.
I'm not a driver expert, but I guess having an ending result printing
all results for all CPUs in case of mismatch is the best choice.
Kind regards,
--
Andrea Cervesato
SUSE QE Automation Engineer Linux
andrea.cervesato@suse.com
--
Mailing list info: https://lists.linux.it/listinfo/ltp
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2026-05-06 12:38 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2026-05-05 9:54 [LTP] [PATCH v10] high_freq_hwp_cap_cppc.c: new test Piotr Kubaj
2026-05-05 17:54 ` [LTP] " linuxtestproject.agent
2026-05-06 12:38 ` [LTP] [PATCH v10] " Andrea Cervesato via ltp
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.