1. Patchew
  2. Xen
  3. [RFC PATCH for-4.22 v2 0/3] Support for Intel temperature sensors (DTS)
  4. View patch

[RFC PATCH for-4.22 v2 2/3] x86/platform: Expose DTS sensors MSR

Teddy Astie posted 3 patches 3 months, 1 week ago
There is a newer version of this series
[RFC PATCH for-4.22 v2 2/3] x86/platform: Expose DTS sensors MSR
Posted by Teddy Astie 3 months, 1 week ago 
Intel provide CPU sensors through "DTS" MSRs. As there 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>
---
v2:
 - move DTS MSR out of legacy list, review MSR naming
 - use CPU policy instead of inline CPUID

 xen/arch/x86/include/asm/msr-index.h | 3 +++
 xen/arch/x86/platform_hypercall.c    | 6 ++++++
 2 files changed, 9 insertions(+)

diff --git a/xen/arch/x86/include/asm/msr-index.h b/xen/arch/x86/include/asm/msr-index.h
index df52587c85..7c6af7bd4d 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_DTS_TEMPERATURE_TARGET          0x000001a2
+#define MSR_DTS_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..d9872ddd3e 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_DTS_TEMPERATURE_TARGET:
+    case MSR_DTS_PACKAGE_THERM_STATUS:
+        return raw_cpu_policy.basic.pm.dts;
     }
 
     if ( ppin_msr && msr == ppin_msr )
-- 
2.51.2



--
Teddy Astie | Vates XCP-ng Developer

XCP-ng & Xen Orchestra - Vates solutions

web: https://vates.tech
Re: [RFC PATCH for-4.22 v2 2/3] x86/platform: Expose DTS sensors MSR
Posted by Jan Beulich 3 months, 1 week ago 
On 29.10.2025 16:59, Teddy Astie wrote:
> --- 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_DTS_TEMPERATURE_TARGET          0x000001a2
> +#define MSR_DTS_PACKAGE_THERM_STATUS        0x000001b1

Where are the DTS infixes coming from? The SDM doesn't have such. We try to
stay as close as reasonable to the SDM / PM names, with the exception that
typically we omit IA32 infixes.

I'd also like to note that unlike the two THERM_STATUS, MSR_TEMPERATURE_TARGET
(as per the absence if an IA32 infix in the SDM) isn't an architectural MSR,
and hence I'm not entirely convinced we can "blindly" expose it. (Interestingly
in Linux code there is an IA32 infix.)

> @@ -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_DTS_TEMPERATURE_TARGET:
> +    case MSR_DTS_PACKAGE_THERM_STATUS:
> +        return raw_cpu_policy.basic.pm.dts;

This, aiui (and according to related comments I got from Andrew on remotely
similar changes I was doing) wants to use host_policy. Hence why that other
prereq change is needed that I talked about (and that iirc I reproduced on
the other sub-thread).

Jan
Re: [RFC PATCH for-4.22 v2 2/3] x86/platform: Expose DTS sensors MSR
Posted by Teddy Astie 3 months, 1 week ago 
Le 30/10/2025 à 14:54, Jan Beulich a écrit :
> On 29.10.2025 16:59, Teddy Astie wrote:
>> --- 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_DTS_TEMPERATURE_TARGET          0x000001a2
>> +#define MSR_DTS_PACKAGE_THERM_STATUS        0x000001b1
> 
> Where are the DTS infixes coming from? The SDM doesn't have such. We try to
> stay as close as reasonable to the SDM / PM names, with the exception that
> typically we omit IA32 infixes.
> 

I got confused with the naming of MSRs (and their lack of IA32 prefix) 
in the upper list of MSR. I guess it should be MSR_PACKAGE_THERM_STATUS 
and MSR_TEMPERATURE_TARGET.

> I'd also like to note that unlike the two THERM_STATUS, MSR_TEMPERATURE_TARGET
> (as per the absence if an IA32 infix in the SDM) isn't an architectural MSR,
> and hence I'm not entirely convinced we can "blindly" expose it. (Interestingly
> in Linux code there is an IA32 infix.)
> 

We only perform rdmsr_safe on this MSR, so I don't think there is much 
problem with it as I don't expect Intel to reuse this MSR number for 
something else (at worst, it is going to not be implemented and would 
gracefully fail).

Some parts of this MSR slightly change, but the one (tjmax) that is 
interesting in here is consistent across the architectures.

>> @@ -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_DTS_TEMPERATURE_TARGET:
>> +    case MSR_DTS_PACKAGE_THERM_STATUS:
>> +        return raw_cpu_policy.basic.pm.dts;
> 
> This, aiui (and according to related comments I got from Andrew on remotely
> similar changes I was doing) wants to use host_policy. Hence why that other
> prereq change is needed that I talked about (and that iirc I reproduced on
> the other sub-thread).
> 

yes

> Jan



--
Teddy Astie | Vates XCP-ng Developer

XCP-ng & Xen Orchestra - Vates solutions

web: https://vates.tech
Re: [RFC PATCH for-4.22 v2 2/3] x86/platform: Expose DTS sensors MSR
Posted by Jan Beulich 3 months ago 
On 03.11.2025 15:30, Teddy Astie wrote:
> Le 30/10/2025 à 14:54, Jan Beulich a écrit :
>> On 29.10.2025 16:59, Teddy Astie wrote:
>> I'd also like to note that unlike the two THERM_STATUS, MSR_TEMPERATURE_TARGET
>> (as per the absence if an IA32 infix in the SDM) isn't an architectural MSR,
>> and hence I'm not entirely convinced we can "blindly" expose it. (Interestingly
>> in Linux code there is an IA32 infix.)
> 
> We only perform rdmsr_safe on this MSR, so I don't think there is much 
> problem with it as I don't expect Intel to reuse this MSR number for 
> something else (at worst, it is going to not be implemented and would 
> gracefully fail).
> 
> Some parts of this MSR slightly change, but the one (tjmax) that is 
> interesting in here is consistent across the architectures.

Perhaps it's indeed okay here, but the aspect needs calling out / justifying in
the description.

Jan

Patchew 2.1-devel-b67e4c2

© 2016 - 2026 Red Hat, Inc.