linux-kernel - Re: [PATCH v2 04/17] x86/resctrl: Detect Assignable Bandwidth Monitoring feature details

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <a3651bc5-55ba-44bf-aef7-503350c49760@amd.com>
Date: Tue, 20 Feb 2024 15:27:55 -0600
From: "Moger, Babu" <babu.moger@....com>
To: James Morse <james.morse@....com>, corbet@....net, fenghua.yu@...el.com,
 reinette.chatre@...el.com, tglx@...utronix.de, mingo@...hat.com,
 bp@...en8.de, dave.hansen@...ux.intel.com
Cc: x86@...nel.org, hpa@...or.com, paulmck@...nel.org, rdunlap@...radead.org,
 tj@...nel.org, peterz@...radead.org, yanjiewtw@...il.com,
 kim.phillips@....com, lukas.bulwahn@...il.com, seanjc@...gle.com,
 jmattson@...gle.com, leitao@...ian.org, jpoimboe@...nel.org,
 rick.p.edgecombe@...el.com, kirill.shutemov@...ux.intel.com,
 jithu.joseph@...el.com, kai.huang@...el.com, kan.liang@...ux.intel.com,
 daniel.sneddon@...ux.intel.com, pbonzini@...hat.com, sandipan.das@....com,
 ilpo.jarvinen@...ux.intel.com, peternewman@...gle.com,
 maciej.wieczor-retman@...el.com, linux-doc@...r.kernel.org,
 linux-kernel@...r.kernel.org, eranian@...gle.com
Subject: Re: [PATCH v2 04/17] x86/resctrl: Detect Assignable Bandwidth
 Monitoring feature details

Hi James,

On 2/20/24 11:56, James Morse wrote:
> Hi Babu,
> 
> On 19/01/2024 18:22, Babu Moger wrote:
>> ABMC feature details are reported via CPUID Fn8000_0020_EBX_x5.
>> Bits Description
>> 15:0 MAX_ABMC Maximum Supported Assignable Bandwidth
>>      Monitoring Counter ID + 1
>>
>> Detect the feature details and update
>> /sys/fs/resctrl/info/L3_MON/mon_features.
>>
>> If the system supports Assignable Bandwidth Monitoring Counters (ABMC),
>> the output will have additional text.
>>  $ cat /sys/fs/resctrl/info/L3_MON/mon_features
>>    mbm_assign_capable
>>
>> The feature details are documented in APM listed below [1].
>> [1] AMD64 Architecture Programmer's Manual Volume 2: System Programming
>> Publication # 24593 Revision 3.41 section 19.3.3.3 Assignable Bandwidth
>> Monitoring (ABMC).
> 
>> diff --git a/arch/x86/kernel/cpu/resctrl/core.c b/arch/x86/kernel/cpu/resctrl/core.c
>> index 4efe2d6a9eb7..f40ee271a5c7 100644
>> --- a/arch/x86/kernel/cpu/resctrl/core.c
>> +++ b/arch/x86/kernel/cpu/resctrl/core.c
>> @@ -303,6 +303,17 @@ static void rdt_get_cdp_l2_config(void)
>>  	rdt_get_cdp_config(RDT_RESOURCE_L2);
>>  }
>>  
>> +static void rdt_get_abmc_cfg(struct rdt_resource *r)
>> +{
>> +	struct rdt_hw_resource *hw_res = resctrl_to_arch_res(r);
>> +	u32 eax, ebx, ecx, edx;
>> +
>> +	r->mbm_assign_capable = true;
>> +	/* Query CPUID_Fn80000020_EBX_x05 for number of ABMC counters */
>> +	cpuid_count(0x80000020, 5, &eax, &ebx, &ecx, &edx);
> 
>> +	hw_res->mbm_assignable_counters = (ebx & 0xFFFF) + 1;
> 
> Please put the mbm_assignable_counters field in struct rdt_resource. The filesystem code
> needs to access this to allocate/free counters and report how many are available.
> After all this gets split and the filesystem code moves to /fs/, the rdt_hw_resrouce
> structure is inaccessible to the filesystem code.

Ok. Sure.

> 
> 
>> +}
>> +
>>  static void
>>  mba_wrmsr_amd(struct rdt_domain *d, struct msr_param *m, struct rdt_resource *r)
>>  {
>> @@ -815,6 +826,12 @@ static __init bool get_rdt_alloc_resources(void)
>>  	if (get_slow_mem_config())
>>  		ret = true;
>>  
>> +	if (rdt_cpu_has(X86_FEATURE_ABMC)) {
>> +		r = &rdt_resources_all[RDT_RESOURCE_L3].r_resctrl;
>> +		rdt_get_abmc_cfg(r);
> 
>> +		ret = true;
> 
> Does it make sense to report rdt_alloc_capable if the SoC has ABMC, but nothing that can
> be configured?

Good catch. Will move it to get_rdt_mon_resources().
> 
> This code would probably make more sense in the get_rdt_mon_resources().

Sure.
> 
> 
>> +	}
>> +
>>  	return ret;
>>  }
>>  
>> diff --git a/arch/x86/kernel/cpu/resctrl/internal.h b/arch/x86/kernel/cpu/resctrl/internal.h
>> index a4f1aa15f0a2..01eb0522b42b 100644
>> --- a/arch/x86/kernel/cpu/resctrl/internal.h
>> +++ b/arch/x86/kernel/cpu/resctrl/internal.h
>> @@ -391,6 +391,8 @@ struct rdt_parse_data {
>>   *			resctrl_arch_get_num_closid() to avoid confusion
>>   *			with struct resctrl_schema's property of the same name,
>>   *			which has been corrected for features like CDP.
> 
>> + * @mbm_assignable_counters:
>> + *			Maximum number of assignable ABMC counters
> 
> As above, please move this to struct rdt_resource. The 'hw' version becomes private to the
> arch code after the move to /fs//
> 
> 
>>   * @msr_base:		Base MSR address for CBMs
>>   * @msr_update:		Function pointer to update QOS MSRs
>>   * @mon_scale:		cqm counter * mon_scale = occupancy in bytes
> 
> 
> Thanks,
> 
> James
> 

-- 
Thanks
Babu Moger