Re: [PATCH v13 00/25] Allow AET to use PMT as loadable module

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

On Mon, Sep 28, 2026 at 05:29:17PM -0700, Luck, Tony wrote:
> Sashiko summary (full version: https://sashiko.dev/#/patchset/20260928221509.68002-1-tony.luck%40intel.com)
> 
> Patch 4: [PATCH v13 04/25] x86/resctrl: Centralize monitoring feature enumeration
> 
> 	Sashiko thinks I broke AMD & Hygon by adding the dependency:
> 
> 		{ X86_FEATURE_CQM_LLC,			X86_FEATURE_CQM       }
> 
> 	and this code:
> 
> 		> +	/* Any monitoring at all? */
> 	> +	if (!cpu_feature_enabled(X86_FEATURE_CQM))
> 	> +		return false;
> 
> 	But Babu said he tested v12 which had this same change. So perhaps bogus?

Sashiko is definitely confused about this. The specific detail from its
report says this:

	While Intel uses CPUID.(EAX=7, ECX=0):EDX[12] to indicate RDT-M capability,
	AMD and Hygon specifications mark this bit as strictly Reserved, and instead
	enumerate L3 QoS capabilities via CPUID leaf 0xF.

But the first part of this is wrong. Sashiko says Intel uses EDX[12],
but the actual bit is in EBX, not EDX. I confirmed that the AMD manual
defines the same CPUID(0x7,0x0)EBX[12] bit to enumerate monitoring.
> 
> 
> Patch 21: [PATCH v13 21/25] x86/resctrl: Export interface to report telemetry unbind/remove
> 
> 	Sashiko says my new locks still have races. This one looks real.  See below(*).
> 
> 	But also a bogus warning that intel_aet_read_event() may be called from
> 	IPI handler on nohz CPUs. All AET events are read from MMIO, so can be
> 	accessed on any CPU, so there is never an smp_call_*() via IPI.
> 
> Patch 22: [PATCH v13 22/25] platform/x86/intel/pmt: Inform resctrl when MMIO maps are being removed
> 
> 	Bogus concern about ACPI telemetry devices. They don't exist.
> 
> ---
> 
> * I asked another AI if it could fix my locking issue. It's given me some
>   slightly complicated code that has some scoped_guard() bits to hold and
>   release locks. I'm staring at it now to see if I like it.

The AI suggestion seems good. I updated patches 18..21 based on the
suggestion and posted as replies to parts 18..21 of this series. Change
log for those since v13 is:

[PATCH v14.1 18/25] x86/resctrl: Use registered function pointers for AET enumeration
	Updates to resolve locking problems reported by Sashiko in v13.

	AET is now going to use a single mutex for both registration
	and in a later patch for device removal. So change the name
	from aet_register_lock to just aet_lock.

	Reverse locking hierarchy between AET and pmt_telemetry.
	No longer OK to call into pmt_telemetry to enumerate
	features with the aet_lock held. Instead, make use of
	module pinning while holding aet_lock.

[PATCH v14.1 19/25] arm,x86,fs/resctrl: Enumerate AET on every resctrl mount
	aet_register_lock name changed to aet_lock.

[PATCH v14.1 20/25] x86/resctrl: Enforce system RMID limit on AET
	No change

[PATCH v14.1 21/25] x86/resctrl: Export interface to report telemetry unbind/remove
	Dropped aet_mmio_lock. Now safe to use aet_lock.

-Tony