Re: [PATCH v6 17/30] x86/resctrl: Discover hardware telemetry events

[Luck, Tony]

On Thu, Jul 03, 2025 at 11:27:19AM -0700, Reinette Chatre wrote:
> Hi Tony,
> 
> On 6/27/25 11:06 AM, Luck, Tony wrote:
> > On Thu, Jun 26, 2025 at 09:49:26AM -0700, Tony Luck wrote:
> >> diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
> >> index 71019b3b54ea..8eb68d2230be 100644
> >> --- a/arch/x86/Kconfig
> >> +++ b/arch/x86/Kconfig
> >> @@ -512,6 +512,9 @@ config X86_CPU_RESCTRL
> >>  	select ARCH_HAS_CPU_RESCTRL
> >>  	select RESCTRL_FS
> >>  	select RESCTRL_FS_PSEUDO_LOCK
> >> +	select X86_PLATFORM_DEVICES
> >> +	select INTEL_VSEC
> >> +	select INTEL_PMT_TELEMETRY
> >>  	help
> >>  	  Enable x86 CPU resource control support.
> >>  
> > 
> > The list of dependencies to "select" keeps growing. "lkp"
> > just told me that "INTEL_VSEC" depends on "PCI".
> > 
> > An alternative approach is to just add:
> > 
> > 	depends on INTEL_PMT_DISCOVERY=y
> > 
> > instead of all the extra "select" lines.
> > 
> > Pro: This describes exactly what is needed. The INTEL_PMT_DISCOVERY
> > driver must be built-in to the kernel so that resctrl can enumerate the
> > telemetry features.
> 
> How will this behave on AMD systems?

The call to intel_pmt_get_regions_by_feature() in the INTEL_PMT_DISCOVERY
driver will return that there are no telemetry events.

If it is a problem to force resctrl users building AMD only kernels
to load the INTEL_PMT_DISCOVERY in order to use resctrl, then I can
look at providing stubs for the entry points in intel_aet.c and
create a new CONFIG option to allow resctrl to be built without
Intel telemetry support.

> > 
> > Con: "make olddefconfig" will now drop X86_CPU_RESCTRL until the user
> > hunts down and enables the chain of dependencies to get RESCTRL turned
> > back on again.
> 
> Reinette
> 

-Tony