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:
 <MW3PR12MB4553D0871C86E1A29E56E77595AC2@MW3PR12MB4553.namprd12.prod.outlook.com>
Date: Thu, 18 Jul 2024 21:11:14 +0000
From: "Moger, Babu" <Babu.Moger@....com>
To: Reinette Chatre <reinette.chatre@...el.com>, "corbet@....net"
	<corbet@....net>, "fenghua.yu@...el.com" <fenghua.yu@...el.com>,
	"tglx@...utronix.de" <tglx@...utronix.de>, "mingo@...hat.com"
	<mingo@...hat.com>, "bp@...en8.de" <bp@...en8.de>,
	"dave.hansen@...ux.intel.com" <dave.hansen@...ux.intel.com>
CC: "x86@...nel.org" <x86@...nel.org>, "hpa@...or.com" <hpa@...or.com>,
	"paulmck@...nel.org" <paulmck@...nel.org>, "rdunlap@...radead.org"
	<rdunlap@...radead.org>, "tj@...nel.org" <tj@...nel.org>,
	"peterz@...radead.org" <peterz@...radead.org>, "yanjiewtw@...il.com"
	<yanjiewtw@...il.com>, "Phillips, Kim" <kim.phillips@....com>,
	"lukas.bulwahn@...il.com" <lukas.bulwahn@...il.com>, "seanjc@...gle.com"
	<seanjc@...gle.com>, "jmattson@...gle.com" <jmattson@...gle.com>,
	"leitao@...ian.org" <leitao@...ian.org>, "jpoimboe@...nel.org"
	<jpoimboe@...nel.org>, "rick.p.edgecombe@...el.com"
	<rick.p.edgecombe@...el.com>, "kirill.shutemov@...ux.intel.com"
	<kirill.shutemov@...ux.intel.com>, "jithu.joseph@...el.com"
	<jithu.joseph@...el.com>, "kai.huang@...el.com" <kai.huang@...el.com>,
	"kan.liang@...ux.intel.com" <kan.liang@...ux.intel.com>,
	"daniel.sneddon@...ux.intel.com" <daniel.sneddon@...ux.intel.com>,
	"pbonzini@...hat.com" <pbonzini@...hat.com>, "Das1, Sandipan"
	<Sandipan.Das@....com>, "ilpo.jarvinen@...ux.intel.com"
	<ilpo.jarvinen@...ux.intel.com>, "peternewman@...gle.com"
	<peternewman@...gle.com>, "maciej.wieczor-retman@...el.com"
	<maciej.wieczor-retman@...el.com>, "linux-doc@...r.kernel.org"
	<linux-doc@...r.kernel.org>, "linux-kernel@...r.kernel.org"
	<linux-kernel@...r.kernel.org>, "eranian@...gle.com" <eranian@...gle.com>,
	"james.morse@....com" <james.morse@....com>
Subject: Re: [PATCH v5 06/20] x86/resctrl: Add support to enable/disable AMD
 ABMC feature

Hi Reinette,

On 7/16/24 12:51, Reinette Chatre wrote:
> Hi Babu,
> 
> On 7/16/24 8:13 AM, Moger, Babu wrote:
>> On 7/12/24 17:05, Reinette Chatre wrote:
>>> On 7/3/24 2:48 PM, Babu Moger wrote:
>>>> Add the functionality to enable/disable AMD ABMC feature.
>>>>
>>>> AMD ABMC feature is enabled by setting enabled bit(0) in MSR
>>>> L3_QOS_EXT_CFG.  When the state of ABMC is changed, the MSR needs
>>>> to be updated on all the logical processors in the QOS Domain.
>>>>
>>>> Hardware counters will reset when ABMC state is changed. Reset the
>>>> architectural state so that reading of hardware counter is not considered
>>>> as an overflow in next update.
>>>>
>>>> The ABMC 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).
>>>>
>>>> Signed-off-by: Babu Moger <babu.moger@....com>
>>>> Link: https://bugzilla.kernel.org/show_bug.cgi?id=206537
>>>> ---
>>>> v5: Renamed resctrl_abmc_enable to resctrl_arch_abmc_enable.
>>>>       Renamed resctrl_abmc_disable to resctrl_arch_abmc_disable.
>>>>       Introduced resctrl_arch_get_abmc_enabled to get abmc state from
>>>>       non-arch code.
>>>>       Renamed resctrl_abmc_set_all to _resctrl_abmc_enable().
>>>>       Modified commit log to make it clear about AMD ABMC feature.
>>>>
>>>> v3: No changes.
>>>>
>>>> v2: Few text changes in commit message.
>>>> ---
>>>>    arch/x86/include/asm/msr-index.h       |  1 +
>>>>    arch/x86/kernel/cpu/resctrl/internal.h | 13 +++++
>>>>    arch/x86/kernel/cpu/resctrl/rdtgroup.c | 66 ++++++++++++++++++++++++++
>>>>    3 files changed, 80 insertions(+)
>>>>
>>>> diff --git a/arch/x86/include/asm/msr-index.h
>>>> b/arch/x86/include/asm/msr-index.h
>>>> index 01342963011e..263b2d9d00ed 100644
>>>> --- a/arch/x86/include/asm/msr-index.h
>>>> +++ b/arch/x86/include/asm/msr-index.h
>>>> @@ -1174,6 +1174,7 @@
>>>>    #define MSR_IA32_MBA_BW_BASE        0xc0000200
>>>>    #define MSR_IA32_SMBA_BW_BASE        0xc0000280
>>>>    #define MSR_IA32_EVT_CFG_BASE        0xc0000400
>>>> +#define MSR_IA32_L3_QOS_EXT_CFG        0xc00003ff
>>>>      /* MSR_IA32_VMX_MISC bits */
>>>>    #define MSR_IA32_VMX_MISC_INTEL_PT                 (1ULL << 14)
>>>> diff --git a/arch/x86/kernel/cpu/resctrl/internal.h
>>>> b/arch/x86/kernel/cpu/resctrl/internal.h
>>>> index 2bd207624eec..0ce9797f80fe 100644
>>>> --- a/arch/x86/kernel/cpu/resctrl/internal.h
>>>> +++ b/arch/x86/kernel/cpu/resctrl/internal.h
>>>> @@ -97,6 +97,9 @@ cpumask_any_housekeeping(const struct cpumask *mask,
>>>> int exclude_cpu)
>>>>        return cpu;
>>>>    }
>>>>    +/* Setting bit 0 in L3_QOS_EXT_CFG enables the ABMC feature */
>>>
>>> Please be consistent throughout series to have sentences end with period.
>>
>> Sure.
>>
>>>
>>>> +#define ABMC_ENABLE            BIT(0)
>>>> +
>>>>    struct rdt_fs_context {
>>>>        struct kernfs_fs_context    kfc;
>>>>        bool                enable_cdpl2;
>>>> @@ -477,6 +480,7 @@ struct rdt_parse_data {
>>>>     * @mbm_cfg_mask:    Bandwidth sources that can be tracked when
>>>> Bandwidth
>>>>     *            Monitoring Event Configuration (BMEC) is supported.
>>>>     * @cdp_enabled:    CDP state of this resource
>>>> + * @abmc_enabled:    ABMC feature is enabled
>>>>     *
>>>>     * Members of this structure are either private to the architecture
>>>>     * e.g. mbm_width, or accessed via helpers that provide
>>>> abstraction. e.g.
>>>> @@ -491,6 +495,7 @@ struct rdt_hw_resource {
>>>>        unsigned int        mbm_width;
>>>>        unsigned int        mbm_cfg_mask;
>>>>        bool            cdp_enabled;
>>>> +    bool            abmc_enabled;
>>>>    };
>>>
>>> mbm_cntr_enabled? This is architecture specific code so there is more
>>> flexibility
>>> here, but it may make implementation easier to understand if consistent
>>> naming is used
>>> between fs and arch code.
>>
>> How about "mbm_cntr_assign_enabled" or "cntr_assign_enabled" ?
> 
> My preference is to keep the term "mbm_cntr" to be consistent with the
> other variables/struct members to help when reading the code.
> "mbm_cntr_assign_enabled" does seem to be getting long though.
> Are you planning to use it by assigning it to a local variable with shorter
> name?
> 
> As a sidenote, I will be offline for large portions of the next few weeks
> and thus unresponsive during this time. I'll be back to a regular
> schedule on August 12th.
> 
I will start working on v6 sometime next week. I will address all the
things which we have discussed already.

We still have to figure out few others items related to displaying the new
interface files when feature ABMC is available vs not available. We can
discuss it with v6.
-- 
Thanks
Babu Moger

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ