linux-kernel - Re: [PATCH 2/2] tools/power/turbostat: Fix division by zero when TDP calculation fails

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] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAJvTdKnjreryLA9KuuobwJShbVseHOyujmXBAXRuSUDsCZxSVA@mail.gmail.com>
Date: Sun, 30 Nov 2025 00:27:08 -0500
From: Len Brown <lenb@...nel.org>
To: "Ehlert, Emily" <ehemily@...zon.de>, "Zhang, Rui" <rui.zhang@...el.com>
Cc: "linux-pm@...r.kernel.org" <linux-pm@...r.kernel.org>, 
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>, Emily Ehlert <ehemily@...zon.com>
Subject: Re: [PATCH 2/2] tools/power/turbostat: Fix division by zero when TDP
 calculation fails

On Fri, Nov 28, 2025 at 9:00 AM Ehlert, Emily <ehemily@...zon.de> wrote:
>
> We are running turbostat inside a VM on the AWS Nitro Hypervisor.
> Guests are not provided with any power measurements. So reading the
> MSR_RAPL_POWER_UNIT will read 0. Since turbostat expects working
> RAPL for this CPU family, failing to read them leads to an exit (because
> setting the the timer fails). I agree that the patch should disable RAPL
> not after TPM but after the RAPL_POWER_UNIT MSR read.
>
> I am not experienced with the way turbostat uses the BIC counter macros.
> It seems like these are mostly used for enabling / disabling individual counters?
> How would I go about using them to disable RAPL in general without affecting
> other MSRs such as CPU%c1 which we can and want to read? I would appreciate
> some pointers or rough outline on how I can approach the issue.

Thanks, that is helpful.
I think we agree that this check should be earlier.

In this scenario, we want to override platform->rapl_msrs -- clearing it because
the MSRs are not actually available...

I cut a patch to replace all the tests of platform->rapl_msrs with a
global variable
that was initialized to (read-only) platform->rapl_msrs, but was
cleared before the test
in rapl_probe_intel(), and when I run with --no-perf (so that
turbostat must use MSRs)
it seems to disable all the RAPL stuff cleanly.

So the question becomes what test to use to determine that we should
not believe platform->,
and we should instead nuke RAPL support?

Once upon a time we used to actually probe the RAPL msrs by trying to read them.
If they failed to read or were zero, we would fail the probe and
disable the couter.
But that turned out to be problematic b/c some platforms had non-zero
unsupported MSRs etc.
so we moved to hard-coding the platform capabilities in a table.

In the VM, does the MSR read fail entirely, or does it just return 0
values for unsupported MSRs?
thanks,
Len Brown, Intel Open Source Technology Center