Re: [PATCH v14 00/24] Allow AET to use PMT as loadable module
From: Luck, Tony
Date: Tue Oct 20 2026 - 12:28:09 EST
On Mon, Oct 19, 2026 at 01:50:07PM -0700, Tony Luck wrote:
> Requiring INTEL_PMT_TELEMETRY=y to enable AET is a functional workaround
> to enable enumeration of Application Energy Telemetry (AET) events, but
> unacceptable to many users. It results in increased configuration complexity,
> increased kernel memory footprint and inability to patch problems by unloading
> a module and loading an updated version.
>
> Add a registration function to the AET code that can be used by
> INTEL_PMT_TELEMETRY to provide the enumeration functions.
>
> INTEL_PMT_TELEMETRY can be loaded/unloaded independently of
> resctrl file system mount/unmount. Perform enumeration on
> every mount and cleanup on every unmount.
Summary of Sashiko review: https://sashiko.dev/#/patchset/20261019205031.16977-1-tony.luck%40intel.com
Only issues in patches 12, 19, 20, 21
* Patch 12: [PATCH v14 12/24] arm,x86,fs/resctrl: Allocate maximum needed rmid_ptrs[]
Looks like a legitimate concern for a somewhat contrived problem. Users
who use kernel command line "clearcpuid" option are always at risk of
running into problems on the invalid h/w configuration they create.
If others think this is worth fixing, I can add additional checks to
intel_aet_get_events().
* Patch 19: [PATCH v14 19/24] x86/resctrl: Enforce system RMID limit on AET
Same complaint as patch 12.
* Patch 20: [PATCH v14 20/24] x86/resctrl: Export interface to report telemetry unbind/remove
Looks like a legitimate report of a race between unbinding/removing
devices in parallel with mounting resctrl. Should I care about this
scenario?
* Patch 21: [PATCH v14 21/24] platform/x86/intel/pmt: Inform resctrl when MMIO maps are being removed
1) Sashiko (still) worried about non-PCI telemetry devices that don't exist.
2) Same device unbind/remove race with mount reported in patch 20.
-Tony