[PATCH v4 0/4] Support for Intel temperature sensors (DTS)

[PATCH v4 0/4] Support for Intel temperature sensors (DTS)

[Teddy Astie]

The idea here is to expose the DTS sensors through XENPF_resource_op
and expose it for the user through xenpm.

v4:
 - reuse original cpu-policy patch
 - remove xenpm building on non-x86
 - add changelog notes
 - reviewed xc_resource_op return code handling
 - only print missing MSR_TEMPERATURE_TARGET message once
 - formatting changes

v3:
 - use msr-index.h instead of adding defines to MSRs in xenpm

v2:
 - moved userland part to xenpm
 - use cpu policy infrastructure instead of inline cpuid_*
 
Jan Beulich (1):
  x86/cpu-policy: define bits of leaf 6

Teddy Astie (3):
  xenpm: Don't build outside of x86
  x86/platform: Expose DTS sensors MSR
  xenpm: Add get-intel-temp subcommand

 CHANGELOG.md                         |   6 ++
 tools/misc/Makefile                  |   2 +-
 tools/misc/xenpm.c                   | 113 ++++++++++++++++++++++++++-
 xen/arch/x86/include/asm/msr-index.h |   3 +
 xen/arch/x86/platform_hypercall.c    |   6 ++
 xen/include/xen/lib/x86/cpu-policy.h |  27 ++++++-
 6 files changed, 154 insertions(+), 3 deletions(-)

-- 
2.51.2



--
Teddy Astie | Vates XCP-ng Developer

XCP-ng & Xen Orchestra - Vates solutions

web: https://vates.tech

[PATCH v4 1/4] x86/cpu-policy: define bits of leaf 6

[Teddy Astie]

From: Jan Beulich <jbeulich@suse.com>

... as far as we presently use them in the codebase.

Signed-off-by: Jan Beulich <jbeulich@suse.com>
Signed-off-by: Teddy Astie <teddy.astie@vates.tech>
---
I don't know to which extend Reviewed-by applies as I only applied Andrew's
proposal.

 xen/include/xen/lib/x86/cpu-policy.h | 27 ++++++++++++++++++++++++++-
 1 file changed, 26 insertions(+), 1 deletion(-)

diff --git a/xen/include/xen/lib/x86/cpu-policy.h b/xen/include/xen/lib/x86/cpu-policy.h
index f94f23e159..8772ef80e3 100644
--- a/xen/include/xen/lib/x86/cpu-policy.h
+++ b/xen/include/xen/lib/x86/cpu-policy.h
@@ -121,7 +121,32 @@ struct cpu_policy
             uint64_t :64, :64; /* Leaf 0x3 - PSN. */
             uint64_t :64, :64; /* Leaf 0x4 - Structured Cache. */
             uint64_t :64, :64; /* Leaf 0x5 - MONITOR. */
-            uint64_t :64, :64; /* Leaf 0x6 - Therm/Perf. */
+
+            /* Leaf 0x6 - Therm/Perf. */
+            bool :1,
+                turbo:1,
+                arat:1,
+                :1,
+                :1,
+                :1,
+                :1,
+                hwp:1,
+                hwp_notification:1,
+                hwp_activity_window:1,
+                hwp_epp:1,
+                hwp_plr:1,
+                :1,
+                hdc:1,
+                :1,
+                :1,
+                hwp_peci:1,
+                :1,
+                :1,
+                hw_feedback:1;
+            uint32_t :32; /* b */
+            bool aperfmperf:1;
+            uint32_t :32; /* d */
+
             uint64_t :64, :64; /* Leaf 0x7 - Structured Features. */
             uint64_t :64, :64; /* Leaf 0x8 - rsvd */
             uint64_t :64, :64; /* Leaf 0x9 - DCA */
-- 
2.51.2



--
Teddy Astie | Vates XCP-ng Developer

XCP-ng & Xen Orchestra - Vates solutions

web: https://vates.tech

Re: [PATCH v4 1/4] x86/cpu-policy: define bits of leaf 6

[Jan Beulich]

On 19.12.2025 16:42, Teddy Astie wrote:
> From: Jan Beulich <jbeulich@suse.com>
> 
> ... as far as we presently use them in the codebase.
> 
> Signed-off-by: Jan Beulich <jbeulich@suse.com>
> Signed-off-by: Teddy Astie <teddy.astie@vates.tech>
> ---
> I don't know to which extend Reviewed-by applies as I only applied Andrew's
> proposal.

Which I pointed out has a latent weakness. I'm intending to submit a new version
of my patch, but instead with the names change to better match the SDM (as was
requested by Andrew in reply to a change later in that other series of mine).

Jan

[PATCH v4 2/4] xenpm: Don't build outside of x86

[Teddy Astie]

xenpm doesn't provide any interesting usable features outside of x86,
skip building it if we are not x86.

Suggested-by: Jan Beulich <jbeulich@suse.com>
Signed-off-by: Teddy Astie <teddy.astie@vates.tech>
---
 CHANGELOG.md        | 3 +++
 tools/misc/Makefile | 2 +-
 2 files changed, 4 insertions(+), 1 deletion(-)

diff --git a/CHANGELOG.md b/CHANGELOG.md
index 3aaf598623..1fa58ce848 100644
--- a/CHANGELOG.md
+++ b/CHANGELOG.md
@@ -16,6 +16,9 @@ The format is based on [Keep a Changelog](https://keepachangelog.com/en/1.0.0/)
      deprecated in Xen 4.7 and noted not to work correctly with AMD CPUs from
      2011 onwards.
 
+ - Removed xenpm on non-x86 platforms as it doesn't actually provide anything
+   useful outside of x86.
+
 ## [4.21.0](https://xenbits.xenproject.org/gitweb/?p=xen.git;a=shortlog;h=RELEASE-4.21.0) - 2025-11-19
 
 ### Changed
diff --git a/tools/misc/Makefile b/tools/misc/Makefile
index c26e544e83..672df02c3b 100644
--- a/tools/misc/Makefile
+++ b/tools/misc/Makefile
@@ -23,13 +23,13 @@ INSTALL_SBIN-$(CONFIG_X86)     += xen-lowmemd
 INSTALL_SBIN-$(CONFIG_X86)     += xen-mceinj
 INSTALL_SBIN-$(CONFIG_X86)     += xen-memshare
 INSTALL_SBIN-$(CONFIG_X86)     += xen-mfndump
+INSTALL_SBIN-$(CONFIG_X86)     += xenpm
 INSTALL_SBIN-$(CONFIG_X86)     += xen-ucode
 INSTALL_SBIN-$(CONFIG_X86)     += xen-vmtrace
 INSTALL_SBIN                   += xencov
 INSTALL_SBIN                   += xenhypfs
 INSTALL_SBIN                   += xenlockprof
 INSTALL_SBIN                   += xenperf
-INSTALL_SBIN                   += xenpm
 INSTALL_SBIN                   += xenwatchdogd
 INSTALL_SBIN                   += xen-access
 INSTALL_SBIN                   += xen-livepatch
-- 
2.51.2



--
Teddy Astie | Vates XCP-ng Developer

XCP-ng & Xen Orchestra - Vates solutions

web: https://vates.tech

Re: [PATCH v4 2/4] xenpm: Don't build outside of x86

[Jan Beulich]

On 19.12.2025 16:42, Teddy Astie wrote:
> xenpm doesn't provide any interesting usable features outside of x86,
> skip building it if we are not x86.
> 
> Suggested-by: Jan Beulich <jbeulich@suse.com>
> Signed-off-by: Teddy Astie <teddy.astie@vates.tech>
> ---
>  CHANGELOG.md        | 3 +++
>  tools/misc/Makefile | 2 +-
>  2 files changed, 4 insertions(+), 1 deletion(-)

Arm being what is mainly affected, I think you may have wanted to Cc Arm folks,
for them to ack this (alongside Anthony).

> --- a/CHANGELOG.md
> +++ b/CHANGELOG.md
> @@ -16,6 +16,9 @@ The format is based on [Keep a Changelog](https://keepachangelog.com/en/1.0.0/)
>       deprecated in Xen 4.7 and noted not to work correctly with AMD CPUs from
>       2011 onwards.
>  
> + - Removed xenpm on non-x86 platforms as it doesn't actually provide anything
> +   useful outside of x86.

Maybe add the word "tool" for those who don't recognize "xenpm" at the first
glance?

Jan

Re: [PATCH v4 2/4] xenpm: Don't build outside of x86

[Anthony PERARD]

On Fri, Dec 19, 2025 at 03:42:17PM +0000, Teddy Astie wrote:
> xenpm doesn't provide any interesting usable features outside of x86,
> skip building it if we are not x86.
> 
> Suggested-by: Jan Beulich <jbeulich@suse.com>
> Signed-off-by: Teddy Astie <teddy.astie@vates.tech>

Happy with that on the Arm side? Julien suggested so on #XenDevel.

For me, this seems fine:
Acked-by: Anthony PERARD <anthony.perard@vates.tech>


> ---
>  CHANGELOG.md        | 3 +++
>  tools/misc/Makefile | 2 +-
>  2 files changed, 4 insertions(+), 1 deletion(-)
> 
> diff --git a/CHANGELOG.md b/CHANGELOG.md
> index 3aaf598623..1fa58ce848 100644
> --- a/CHANGELOG.md
> +++ b/CHANGELOG.md
> @@ -16,6 +16,9 @@ The format is based on [Keep a Changelog](https://keepachangelog.com/en/1.0.0/)
>       deprecated in Xen 4.7 and noted not to work correctly with AMD CPUs from
>       2011 onwards.
>  
> + - Removed xenpm on non-x86 platforms as it doesn't actually provide anything
> +   useful outside of x86.
> +
>  ## [4.21.0](https://xenbits.xenproject.org/gitweb/?p=xen.git;a=shortlog;h=RELEASE-4.21.0) - 2025-11-19
>  
>  ### Changed
> diff --git a/tools/misc/Makefile b/tools/misc/Makefile
> index c26e544e83..672df02c3b 100644
> --- a/tools/misc/Makefile
> +++ b/tools/misc/Makefile
> @@ -23,13 +23,13 @@ INSTALL_SBIN-$(CONFIG_X86)     += xen-lowmemd
>  INSTALL_SBIN-$(CONFIG_X86)     += xen-mceinj
>  INSTALL_SBIN-$(CONFIG_X86)     += xen-memshare
>  INSTALL_SBIN-$(CONFIG_X86)     += xen-mfndump
> +INSTALL_SBIN-$(CONFIG_X86)     += xenpm

Nit: I would sort this by taking the dash `-` into account since we do
so for the arch-common list, so xenpm would go after xen-vmtrace.

>  INSTALL_SBIN-$(CONFIG_X86)     += xen-ucode
>  INSTALL_SBIN-$(CONFIG_X86)     += xen-vmtrace
>  INSTALL_SBIN                   += xencov
>  INSTALL_SBIN                   += xenhypfs
>  INSTALL_SBIN                   += xenlockprof
>  INSTALL_SBIN                   += xenperf
> -INSTALL_SBIN                   += xenpm
>  INSTALL_SBIN                   += xenwatchdogd
>  INSTALL_SBIN                   += xen-access
>  INSTALL_SBIN                   += xen-livepatch

-- 
Anthony PERARD

Re: [PATCH v4 2/4] xenpm: Don't build outside of x86

[Jan Beulich]

On 07.01.2026 16:58, Anthony PERARD wrote:
> On Fri, Dec 19, 2025 at 03:42:17PM +0000, Teddy Astie wrote:
>> --- a/tools/misc/Makefile
>> +++ b/tools/misc/Makefile
>> @@ -23,13 +23,13 @@ INSTALL_SBIN-$(CONFIG_X86)     += xen-lowmemd
>>  INSTALL_SBIN-$(CONFIG_X86)     += xen-mceinj
>>  INSTALL_SBIN-$(CONFIG_X86)     += xen-memshare
>>  INSTALL_SBIN-$(CONFIG_X86)     += xen-mfndump
>> +INSTALL_SBIN-$(CONFIG_X86)     += xenpm
> 
> Nit: I would sort this by taking the dash `-` into account since we do
> so for the arch-common list, so xenpm would go after xen-vmtrace.

Not really; imo it's coincidental that all present x86-only ones have a
dash. I think this simply wants to ...

>>  INSTALL_SBIN-$(CONFIG_X86)     += xen-ucode
>>  INSTALL_SBIN-$(CONFIG_X86)     += xen-vmtrace
>>  INSTALL_SBIN                   += xencov
>>  INSTALL_SBIN                   += xenhypfs
>>  INSTALL_SBIN                   += xenlockprof
>>  INSTALL_SBIN                   += xenperf
>> -INSTALL_SBIN                   += xenpm

... stay in its present place, merely becoming conditional.

>>  INSTALL_SBIN                   += xenwatchdogd
>>  INSTALL_SBIN                   += xen-access
>>  INSTALL_SBIN                   += xen-livepatch

The three entries with dashes quite likely were blindly added to the tail,
without paying attention to sorting. Imo they want moving up into their
respective positions.

Jan

[PATCH v4 3/4] x86/platform: Expose DTS sensors MSR

[Teddy Astie]

Intel provide CPU sensors through "DTS" MSRs. As these MSR are core-specific
(or package-specific), we can't reliably fetch them from Dom0 directly.
Expose these MSR (if supported) through XENPF_resource_op so that it is
accessible through hypercall.

Suggested-by: Jan Beulich <jbeulich@suse.com>
Signed-off-by: Teddy Astie <teddy.astie@vates.tech>
---
 xen/arch/x86/include/asm/msr-index.h | 3 +++
 xen/arch/x86/platform_hypercall.c    | 6 ++++++
 xen/include/xen/lib/x86/cpu-policy.h | 2 +-
 3 files changed, 10 insertions(+), 1 deletion(-)

diff --git a/xen/arch/x86/include/asm/msr-index.h b/xen/arch/x86/include/asm/msr-index.h
index df52587c85..b92a278611 100644
--- a/xen/arch/x86/include/asm/msr-index.h
+++ b/xen/arch/x86/include/asm/msr-index.h
@@ -115,6 +115,9 @@
 #define  MCU_OPT_CTRL_GDS_MIT_DIS           (_AC(1, ULL) <<  4)
 #define  MCU_OPT_CTRL_GDS_MIT_LOCK          (_AC(1, ULL) <<  5)
 
+#define MSR_TEMPERATURE_TARGET              0x000001a2
+#define MSR_PACKAGE_THERM_STATUS            0x000001b1
+
 #define MSR_FRED_RSP_SL0                    0x000001cc
 #define MSR_FRED_RSP_SL1                    0x000001cd
 #define MSR_FRED_RSP_SL2                    0x000001ce
diff --git a/xen/arch/x86/platform_hypercall.c b/xen/arch/x86/platform_hypercall.c
index 79bb99e0b6..2f84494759 100644
--- a/xen/arch/x86/platform_hypercall.c
+++ b/xen/arch/x86/platform_hypercall.c
@@ -27,6 +27,7 @@
 #include <asm/current.h>
 #include <public/platform.h>
 #include <acpi/cpufreq/processor_perf.h>
+#include <asm/cpu-policy.h>
 #include <asm/edd.h>
 #include <asm/microcode.h>
 #include <asm/mtrr.h>
@@ -86,6 +87,11 @@ static bool msr_read_allowed(unsigned int msr)
 
     case MSR_MCU_OPT_CTRL:
         return cpu_has_srbds_ctrl;
+    
+    case MSR_IA32_THERM_STATUS:
+    case MSR_TEMPERATURE_TARGET:
+    case MSR_PACKAGE_THERM_STATUS:
+        return host_cpu_policy.basic.dts;
     }
 
     if ( ppin_msr && msr == ppin_msr )
diff --git a/xen/include/xen/lib/x86/cpu-policy.h b/xen/include/xen/lib/x86/cpu-policy.h
index 8772ef80e3..0362f1cb24 100644
--- a/xen/include/xen/lib/x86/cpu-policy.h
+++ b/xen/include/xen/lib/x86/cpu-policy.h
@@ -123,7 +123,7 @@ struct cpu_policy
             uint64_t :64, :64; /* Leaf 0x5 - MONITOR. */
 
             /* Leaf 0x6 - Therm/Perf. */
-            bool :1,
+            bool dts:1,
                 turbo:1,
                 arat:1,
                 :1,
-- 
2.51.2



--
Teddy Astie | Vates XCP-ng Developer

XCP-ng & Xen Orchestra - Vates solutions

web: https://vates.tech

Re: [PATCH v4 3/4] x86/platform: Expose DTS sensors MSR

[Jan Beulich]

On 19.12.2025 16:42, Teddy Astie wrote:
> Intel provide CPU sensors through "DTS" MSRs. As these MSR are core-specific
> (or package-specific), we can't reliably fetch them from Dom0 directly.
> Expose these MSR (if supported) through XENPF_resource_op so that it is
> accessible through hypercall.
> 
> Suggested-by: Jan Beulich <jbeulich@suse.com>
> Signed-off-by: Teddy Astie <teddy.astie@vates.tech>

Reviewed-by: Jan Beulich <jbeulich@suse.com>

I wonder though whether ...

> --- a/xen/include/xen/lib/x86/cpu-policy.h
> +++ b/xen/include/xen/lib/x86/cpu-policy.h
> @@ -123,7 +123,7 @@ struct cpu_policy
>              uint64_t :64, :64; /* Leaf 0x5 - MONITOR. */
>  
>              /* Leaf 0x6 - Therm/Perf. */
> -            bool :1,
> +            bool dts:1,

... we really want to go with the acronym here, when for other bits the plan
now is to stay close to the SDM names.

Jan

[PATCH v4 4/4] xenpm: Add get-intel-temp subcommand

[Teddy Astie]

get-intel-temp allows querying the per-core CPU temperature and
per-package one on Intel processors (as usual Dom0 drivers cannot
work due to misalignment between Dom0 vCPU and pCPUs).

Signed-off-by: Teddy Astie <teddy.astie@vates.tech>
---
 CHANGELOG.md       |   3 ++
 tools/misc/xenpm.c | 113 ++++++++++++++++++++++++++++++++++++++++++++-
 2 files changed, 115 insertions(+), 1 deletion(-)

diff --git a/CHANGELOG.md b/CHANGELOG.md
index 1fa58ce848..f55d77016c 100644
--- a/CHANGELOG.md
+++ b/CHANGELOG.md
@@ -9,6 +9,9 @@ The format is based on [Keep a Changelog](https://keepachangelog.com/en/1.0.0/)
 ### Changed

 ### Added
+ - On x86:
+   - Introduce get-intel-temp to xenpm to query CPU temperatures on Intel
+     platforms.

 ### Removed
  - On x86:
diff --git a/tools/misc/xenpm.c b/tools/misc/xenpm.c
index 682d092479..5a411b5a30 100644
--- a/tools/misc/xenpm.c
+++ b/tools/misc/xenpm.c
@@ -32,11 +32,14 @@

 #include <xen-tools/common-macros.h>

+#include <xen/asm/msr-index.h>
+
 #define MAX_PKG_RESIDENCIES 12
 #define MAX_CORE_RESIDENCIES 8

 static xc_interface *xc_handle;
 static unsigned int max_cpu_nr;
+static xc_physinfo_t physinfo;

 /* help message */
 void show_help(void)
@@ -93,6 +96,7 @@ void show_help(void)
             "                                           units default to \"us\" if unspecified.\n"
             "                                           truncates un-representable values.\n"
             "                                           0 lets the hardware decide.\n"
+            " get-intel-temp        [cpuid]       get Intel CPU temperature of <cpuid> or all\n"
             " start [seconds]                     start collect Cx/Px statistics,\n"
             "                                     output after CTRL-C or SIGINT or several seconds.\n"
             " enable-turbo-mode     [cpuid]       enable Turbo Mode for processors that support it.\n"
@@ -1354,6 +1358,113 @@ void enable_turbo_mode(int argc, char *argv[])
                 errno, strerror(errno));
 }

+static int fetch_dts_temp(xc_interface *xch, uint32_t cpu, bool package, int *temp)
+{
+    xc_resource_entry_t entries[] = {
+        { .idx = package ? MSR_PACKAGE_THERM_STATUS : MSR_IA32_THERM_STATUS },
+        { .idx = MSR_TEMPERATURE_TARGET },
+    };
+    struct xc_resource_op ops = {
+        .cpu = cpu,
+        .entries = entries,
+        .nr_entries = ARRAY_SIZE(entries),
+    };
+    int tjmax;
+
+    int ret = xc_resource_op(xch, 1, &ops);
+
+    switch ( ret )
+    {
+    case -1:
+        /* xc_resource_op returns -1 in out of memory scenarios */
+        return -ENOMEM;
+    case 0:
+        /* This CPU isn't online or can't query this MSR */
+        return -ENODATA;
+    case 1:
+    {
+        /*
+         * The CPU doesn't support MSR_TEMPERATURE_TARGET, we assume it's 100
+         * which is correct aside a few selected Atom CPUs. Check Linux
+         * kernel's coretemp.c for more information.
+         */
+        static bool has_reported_once = false;
+
+        if ( !has_reported_once )
+        {
+            fprintf(stderr, "MSR_TEMPERATURE_TARGET is not supported, assume "
+                            "tjmax = 100, readings may be incorrect.\n");
+            has_reported_once = true;
+        }
+
+        tjmax = 100;
+        break;
+    }
+    case 2:
+    {
+        tjmax = (entries[1].val >> 16) & 0xff;
+        break;
+    }
+    default:
+        if ( ret > 0 )
+        {
+            fprintf(stderr, "Got unexpected xc_resource_op return value: %d",
+                    ret);
+            return -EINVAL;
+        }
+        return ret;
+    }
+
+    *temp = tjmax - ((entries[0].val >> 16) & 0xff);
+    return 0;
+}
+
+static void get_intel_temp(int argc, char *argv[])
+{
+    int temp = -1, cpu = -1;
+    unsigned int socket;
+    bool has_data = false;
+
+    if ( argc > 0 )
+        parse_cpuid(argv[0], &cpu);
+
+    if ( cpu != -1 )
+    {
+        if ( !fetch_dts_temp(xc_handle, cpu, false, &temp) )
+            printf("CPU%d: %d°C\n", cpu, temp);
+        else
+            printf("No data\n");
+        return;
+    }
+
+    /* Per socket measurement */
+    for ( socket = 0, cpu = 0; cpu < max_cpu_nr;
+          socket++, cpu += physinfo.cores_per_socket * physinfo.threads_per_core )
+    {
+        if ( !fetch_dts_temp(xc_handle, cpu, true, &temp) )
+        {
+            has_data = true;
+            printf("Package%u: %d°C\n", socket, temp);
+        }
+    }
+
+    if ( has_data )
+        /* Avoid inserting a trailing line if we have nothing */
+        printf("\n");
+
+    for ( cpu = 0; cpu < max_cpu_nr; cpu += physinfo.threads_per_core )
+    {
+        if ( fetch_dts_temp(xc_handle, cpu, false, &temp) )
+            continue;
+
+        has_data = true;
+        printf("CPU%d: %d°C\n", cpu, temp);
+    }
+
+    if ( !has_data )
+        printf("No data\n");
+}
+
 void disable_turbo_mode(int argc, char *argv[])
 {
     int cpuid = -1;
@@ -1618,12 +1729,12 @@ struct {
     { "set-max-cstate", set_max_cstate_func},
     { "enable-turbo-mode", enable_turbo_mode },
     { "disable-turbo-mode", disable_turbo_mode },
+    { "get-intel-temp", get_intel_temp },
 };

 int main(int argc, char *argv[])
 {
     int i, ret = 0;
-    xc_physinfo_t physinfo;
     int nr_matches = 0;
     int matches_main_options[ARRAY_SIZE(main_options)];

--
2.51.2



--
Teddy Astie | Vates XCP-ng Developer

XCP-ng & Xen Orchestra - Vates solutions

web: https://vates.tech

Re: [PATCH v4 4/4] xenpm: Add get-intel-temp subcommand

[Jan Beulich]

On 19.12.2025 16:42, Teddy Astie wrote:
> @@ -1354,6 +1358,113 @@ void enable_turbo_mode(int argc, char *argv[])
>                  errno, strerror(errno));
>  }
>  
> +static int fetch_dts_temp(xc_interface *xch, uint32_t cpu, bool package, int *temp)
> +{
> +    xc_resource_entry_t entries[] = {
> +        { .idx = package ? MSR_PACKAGE_THERM_STATUS : MSR_IA32_THERM_STATUS },
> +        { .idx = MSR_TEMPERATURE_TARGET },
> +    };
> +    struct xc_resource_op ops = {
> +        .cpu = cpu,
> +        .entries = entries,
> +        .nr_entries = ARRAY_SIZE(entries),
> +    };
> +    int tjmax;
> +
> +    int ret = xc_resource_op(xch, 1, &ops);
> +
> +    switch ( ret )
> +    {
> +    case -1:
> +        /* xc_resource_op returns -1 in out of memory scenarios */
> +        return -ENOMEM;
> +    case 0:
> +        /* This CPU isn't online or can't query this MSR */
> +        return -ENODATA;
> +    case 1:
> +    {
> +        /*
> +         * The CPU doesn't support MSR_TEMPERATURE_TARGET, we assume it's 100
> +         * which is correct aside a few selected Atom CPUs. Check Linux
> +         * kernel's coretemp.c for more information.
> +         */
> +        static bool has_reported_once = false;
> +
> +        if ( !has_reported_once )
> +        {
> +            fprintf(stderr, "MSR_TEMPERATURE_TARGET is not supported, assume "
> +                            "tjmax = 100, readings may be incorrect.\n");
> +            has_reported_once = true;
> +        }
> +
> +        tjmax = 100;
> +        break;
> +    }
> +    case 2:
> +    {
> +        tjmax = (entries[1].val >> 16) & 0xff;
> +        break;
> +    }

No need for figure braces here; you don't have ones either in cases further up
where there are no new local variables. Instead a blank line between non-fall-
through case blocks may be nice.

Jan