Re: [PATCH v2 0/5] thermal: intel: Add support for Directed Package Thermal Interrupt

[Rafael J. Wysocki]

On Thu, May 28, 2026 at 5:15 PM Ricardo Neri
<ricardo.neri-calderon@xxxxxxxxxxxxxxx> wrote:
>
> Hi,
>
> This is v2 of this series. The main changes are a new patch fixing a pre-
> existing bug and a redesigned error rollback strategy that disables
> directed thermal interrupts across all packages when enabling fails in any
> one of them. Please see the changelog for details.
>
> Package-level thermal interrupts are currently broadcast to all CPUs in a
> package. Only one CPU is needed to service package-wide events.
> Broadcasting creates unnecessary resource contention. Thermal interrupts
> generated for Hardware Feedback Interface[1] updates are an example: all
> CPUs in the package receive the interrupt and race for a lock to update a
> shared data structure. Idle CPUs are needlessly woken up.
>
> Newer Intel processors allow directing package-level thermal interrupts
> only to CPUs that explicitly request them. A CPU opts in by setting a
> designated bit in IA32_THERM_INTERRUPT. Hardware acknowledges the request
> by setting a designated bit in IA32_PACKAGE_THERM_STATUS.
>
> This series enables directed package-level thermal interrupts and
> designates one handler CPU per package using the CPU hotplug
> infrastructure. A new CPU is selected if the handler CPU goes offline.
>
> Because CPU0's hotplug callbacks are not invoked during suspend and resume,
> syscore callbacks are added to restore the handler for the boot package.
> The series also disables directed delivery during kexec reboot, avoiding
> stale interrupt routing when rebooting into a kernel that does not support
> the feature.
>
> This patchset introduces a change in behavior in the /sys/devices/system/
> cpu/cpuN/thermal_throttle/package* sysfs files. These files reflect per-CPU
> variables updated when a CPU handles a package-level thermal interrupt. In
> broadcast mode, all CPUs update their variables. When directed package-
> level thermal interrupts are enabled, only the handler CPU's variables are
> updated.
>
> Lastly, nothing changes for processors that do not support this feature:
> they fall back to broadcast delivery.
>
> [1] Intel Software Developer's Manual Vol. 3, Section 17.6, March 2026 https://www.intel.com/SDM
>
> Signed-off-by: Ricardo Neri <ricardo.neri-calderon@xxxxxxxxxxxxxxx>
> ---
> Changes in v2:
> - Fixed an existing bug in the error-handling of thermal_throttle_online()
>   CPU hotplug callback.
> - Redesigned the rollback mechanism to handle all packages, not only
>   the boot package.
> - Fixed the handling of the return value of cpumask_any_but(), which on
>   failure returns small_cpumask_bits, not nr_cpu_ids.
> - Renamed the Directed Package Thermal Interrupt CPUID and MSR bits for
>   consistency and brevity. (Boris)
> - Added measurements of the latency of setup acknowledgment from hardware.
> - Removed an unused argument from directed_thermal_pkg_intr_supported().
> - Reused the global rollback mechanism in the syscore shutdown callback.
> - Link to v1: https://lore.kernel.org/r/20260309-rneri-directed-therm-intr-v1-0-2956e3000950@xxxxxxxxxxxxxxx
>
> ---
> Ricardo Neri (5):
>       thermal: intel: Fix dangling resources on thermal_throttle_online() failure
>       x86/thermal: Add bit definitions for Intel Directed Package Thermal Interrupt
>       thermal: intel: Enable the Directed Package-level Thermal Interrupt
>       thermal: intel: Add syscore callbacks for suspend and resume
>       thermal: intel: Add a syscore shutdown callback for kexec reboot
>
>  arch/x86/include/asm/cpufeatures.h  |   2 +
>  arch/x86/include/asm/msr-index.h    |   2 +
>  drivers/thermal/intel/therm_throt.c | 272 +++++++++++++++++++++++++++++++++++-
>  3 files changed, 272 insertions(+), 4 deletions(-)
> ---

sashiko.dev has some feedback on patch 4 that appears to be valid to me:

https://sashiko.dev/#/patchset/20260528-rneri-directed-therm-intr-v2-0-8e2f9e0c1a36%40linux.intel.com

Can you have a look at it please?