Re: [PATCH v14 00/24] Allow AET to use PMT as loadable module

["Luck, Tony" <tony.luck@intel.com>]

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