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

[Reinette Chatre]

Hi Tony,

On 7/3/25 1:17 PM, Luck, Tony wrote:
> On Thu, Jul 03, 2025 at 11:27:19AM -0700, Reinette Chatre wrote:
>> 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.

I do not think resctrl should enforce dependency on a driver that is not
valid for a platform.

Reinette