[PATCH v7 15/24] x86/resctrl: Implement resctrl_arch_assign_cntr to assign a counter with ABMC

Babu Moger posted 24 patches 1 year, 3 months ago
There is a newer version of this series
[PATCH v7 15/24] x86/resctrl: Implement resctrl_arch_assign_cntr to assign a counter with ABMC
Posted by Babu Moger 1 year, 3 months ago
The ABMC feature provides an option to the user to assign a hardware
counter to an RMID, event pair and monitor the bandwidth as long as it is
assigned. The assigned RMID will be tracked by the hardware until the user
unassigns it manually.

Counters are configured by writing to L3_QOS_ABMC_CFG MSR and
specifying the counter id, bandwidth source, and bandwidth types.

Provide the interface to assign the counter ids to RMID.

The feature details are documented in the 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).

Link: https://bugzilla.kernel.org/show_bug.cgi?id=206537
Signed-off-by: Babu Moger <babu.moger@amd.com>
---
v7: Separated arch and fs functions. This patch only has arch implementation.
    Added struct rdt_resource to the interface resctrl_arch_assign_cntr.
    Rename rdtgroup_abmc_cfg() to resctrl_abmc_config_one_amd().

v6: Removed mbm_cntr_alloc() from this patch to keep fs and arch code
    separate.
    Added code to update the counter assignment at domain level.

v5: Few name changes to match cntr_id.
    Changed the function names to
      rdtgroup_assign_cntr
      resctr_arch_assign_cntr
      More comments on commit log.
      Added function summary.

v4: Commit message update.
      User bitmap APIs where applicable.
      Changed the interfaces considering MPAM(arm).
      Added domain specific assignment.

v3: Removed the static from the prototype of rdtgroup_assign_abmc.
      The function is not called directly from user anymore. These
      changes are related to global assignment interface.

v2: Minor text changes in commit message.
---
 arch/x86/kernel/cpu/resctrl/internal.h |  3 ++
 arch/x86/kernel/cpu/resctrl/rdtgroup.c | 45 ++++++++++++++++++++++++++
 2 files changed, 48 insertions(+)

diff --git a/arch/x86/kernel/cpu/resctrl/internal.h b/arch/x86/kernel/cpu/resctrl/internal.h
index e0ae8b0b45b2..57c31615eae7 100644
--- a/arch/x86/kernel/cpu/resctrl/internal.h
+++ b/arch/x86/kernel/cpu/resctrl/internal.h
@@ -702,6 +702,9 @@ int mbm_cntr_alloc(struct rdt_resource *r);
 void mbm_cntr_free(struct rdt_resource *r, u32 cntr_id);
 void resctrl_mbm_evt_config_init(struct rdt_hw_mon_domain *hw_dom);
 unsigned int mon_event_config_index_get(u32 evtid);
+int resctrl_arch_assign_cntr(struct rdt_resource *r, struct rdt_mon_domain *d,
+			     enum resctrl_event_id evtid, u32 rmid, u32 closid,
+			     u32 cntr_id, bool assign);
 void rdt_staged_configs_clear(void);
 bool closid_allocated(unsigned int closid);
 int resctrl_find_cleanest_closid(void);
diff --git a/arch/x86/kernel/cpu/resctrl/rdtgroup.c b/arch/x86/kernel/cpu/resctrl/rdtgroup.c
index 7fa92143daa7..7ad653b4e768 100644
--- a/arch/x86/kernel/cpu/resctrl/rdtgroup.c
+++ b/arch/x86/kernel/cpu/resctrl/rdtgroup.c
@@ -1853,6 +1853,51 @@ static ssize_t mbm_local_bytes_config_write(struct kernfs_open_file *of,
 	return ret ?: nbytes;
 }
 
+static void resctrl_abmc_config_one_amd(void *info)
+{
+	u64 *msrval = info;
+
+	wrmsrl(MSR_IA32_L3_QOS_ABMC_CFG, *msrval);
+}
+
+/*
+ * Send an IPI to the domain to assign the counter to RMID, event pair.
+ */
+int resctrl_arch_assign_cntr(struct rdt_resource *r, struct rdt_mon_domain *d,
+			     enum resctrl_event_id evtid, u32 rmid, u32 closid,
+			     u32 cntr_id, bool assign)
+{
+	struct rdt_hw_mon_domain *hw_dom = resctrl_to_arch_mon_dom(d);
+	union l3_qos_abmc_cfg abmc_cfg = { 0 };
+	struct arch_mbm_state *arch_mbm;
+
+	abmc_cfg.split.cfg_en = 1;
+	abmc_cfg.split.cntr_en = assign ? 1 : 0;
+	abmc_cfg.split.cntr_id = cntr_id;
+	abmc_cfg.split.bw_src = rmid;
+
+	/* Update the event configuration from the domain */
+	if (evtid == QOS_L3_MBM_TOTAL_EVENT_ID) {
+		abmc_cfg.split.bw_type = hw_dom->mbm_total_cfg;
+		arch_mbm = &hw_dom->arch_mbm_total[rmid];
+	} else {
+		abmc_cfg.split.bw_type = hw_dom->mbm_local_cfg;
+		arch_mbm = &hw_dom->arch_mbm_local[rmid];
+	}
+
+	smp_call_function_any(&d->hdr.cpu_mask, resctrl_abmc_config_one_amd,
+			      &abmc_cfg, 1);
+
+	/*
+	 * Reset the architectural state so that reading of hardware
+	 * counter is not considered as an overflow in next update.
+	 */
+	if (arch_mbm)
+		memset(arch_mbm, 0, sizeof(struct arch_mbm_state));
+
+	return 0;
+}
+
 /* rdtgroup information files for one cache resource. */
 static struct rftype res_common_files[] = {
 	{
-- 
2.34.1
Re: [PATCH v7 15/24] x86/resctrl: Implement resctrl_arch_assign_cntr to assign a counter with ABMC
Posted by Reinette Chatre 1 year, 3 months ago
Hi Babu,

In subject, please use "()" for a function.

On 9/4/24 3:21 PM, Babu Moger wrote:
> +/*
> + * Send an IPI to the domain to assign the counter to RMID, event pair.
> + */
> +int resctrl_arch_assign_cntr(struct rdt_resource *r, struct rdt_mon_domain *d,
> +			     enum resctrl_event_id evtid, u32 rmid, u32 closid,
> +			     u32 cntr_id, bool assign)

Looking ahead this is also called when config of existing assigned counter is
changed. Should this thus perhaps be resctrl_arch_config_cntr()? 

> +{
> +	struct rdt_hw_mon_domain *hw_dom = resctrl_to_arch_mon_dom(d);
> +	union l3_qos_abmc_cfg abmc_cfg = { 0 };
> +	struct arch_mbm_state *arch_mbm;
> +
> +	abmc_cfg.split.cfg_en = 1;

Just to confirm ... a counter remains "configured" from the hardware side whether it
is assigned from resctrl perspective or not? It seems to me that once a counter is
"unassigned" from resctrl perspective it needs no more context about that
counter, yet it remains configured from hardware side?

Reinette
Re: [PATCH v7 15/24] x86/resctrl: Implement resctrl_arch_assign_cntr to assign a counter with ABMC
Posted by Moger, Babu 1 year, 2 months ago
Hi Reinette,

On 9/19/24 12:13, Reinette Chatre wrote:
> Hi Babu,
> 
> In subject, please use "()" for a function.

Sure.

> 
> On 9/4/24 3:21 PM, Babu Moger wrote:
>> +/*
>> + * Send an IPI to the domain to assign the counter to RMID, event pair.
>> + */
>> +int resctrl_arch_assign_cntr(struct rdt_resource *r, struct rdt_mon_domain *d,
>> +			     enum resctrl_event_id evtid, u32 rmid, u32 closid,
>> +			     u32 cntr_id, bool assign)
> 
> Looking ahead this is also called when config of existing assigned counter is
> changed. Should this thus perhaps be resctrl_arch_config_cntr()? 

We have a matching resctrl_arch_assign_cntr() and
resctrl_arch_unassign_cntr() pair.

If we change resctrl_arch_config_cntr() then we need to change
resctrl_arch_unassign_cntr to resctrl_arch_unconfig_cntr().

Should we change both?


> 
>> +{
>> +	struct rdt_hw_mon_domain *hw_dom = resctrl_to_arch_mon_dom(d);
>> +	union l3_qos_abmc_cfg abmc_cfg = { 0 };
>> +	struct arch_mbm_state *arch_mbm;
>> +
>> +	abmc_cfg.split.cfg_en = 1;
> 
> Just to confirm ... a counter remains "configured" from the hardware side whether it
> is assigned from resctrl perspective or not? It seems to me that once a counter is
> "unassigned" from resctrl perspective it needs no more context about that
> counter, yet it remains configured from hardware side?

That is correct.
When unassigned, we are setting cntr_en = 0, so there is no counting. But
in hardware perspective it is still configured.
-- 
Thanks
Babu Moger
Re: [PATCH v7 15/24] x86/resctrl: Implement resctrl_arch_assign_cntr to assign a counter with ABMC
Posted by Reinette Chatre 1 year, 2 months ago
Hi Babu,

On 9/23/24 2:03 PM, Moger, Babu wrote:
> Hi Reinette,
> 
> On 9/19/24 12:13, Reinette Chatre wrote:
>> Hi Babu,
>>
>> In subject, please use "()" for a function.
> 
> Sure.
> 
>>
>> On 9/4/24 3:21 PM, Babu Moger wrote:
>>> +/*
>>> + * Send an IPI to the domain to assign the counter to RMID, event pair.
>>> + */
>>> +int resctrl_arch_assign_cntr(struct rdt_resource *r, struct rdt_mon_domain *d,
>>> +			     enum resctrl_event_id evtid, u32 rmid, u32 closid,
>>> +			     u32 cntr_id, bool assign)
>>
>> Looking ahead this is also called when config of existing assigned counter is
>> changed. Should this thus perhaps be resctrl_arch_config_cntr()? 
> 
> We have a matching resctrl_arch_assign_cntr() and
> resctrl_arch_unassign_cntr() pair.

hmmm ... resctrl_arch_unassign_cntr() does not exist in this version of the series.

> 
> If we change resctrl_arch_config_cntr() then we need to change
> resctrl_arch_unassign_cntr to resctrl_arch_unconfig_cntr().
> 
> Should we change both?
> 
> 
>>
>>> +{
>>> +	struct rdt_hw_mon_domain *hw_dom = resctrl_to_arch_mon_dom(d);
>>> +	union l3_qos_abmc_cfg abmc_cfg = { 0 };
>>> +	struct arch_mbm_state *arch_mbm;
>>> +
>>> +	abmc_cfg.split.cfg_en = 1;
>>
>> Just to confirm ... a counter remains "configured" from the hardware side whether it
>> is assigned from resctrl perspective or not? It seems to me that once a counter is
>> "unassigned" from resctrl perspective it needs no more context about that
>> counter, yet it remains configured from hardware side?
> 
> That is correct.
> When unassigned, we are setting cntr_en = 0, so there is no counting. But
> in hardware perspective it is still configured.

I think I misunderstood the "configured in hardware" to equate to "assigned by
OS" when in fact it is just a bit to indicate when hardware makes changes
requested by MSR write.

Reinette
Re: [PATCH v7 15/24] x86/resctrl: Implement resctrl_arch_assign_cntr to assign a counter with ABMC
Posted by Moger, Babu 1 year, 2 months ago
Hi Reinette,

On 9/23/24 17:29, Reinette Chatre wrote:
> Hi Babu,
> 
> On 9/23/24 2:03 PM, Moger, Babu wrote:
>> Hi Reinette,
>>
>> On 9/19/24 12:13, Reinette Chatre wrote:
>>> Hi Babu,
>>>
>>> In subject, please use "()" for a function.
>>
>> Sure.
>>
>>>
>>> On 9/4/24 3:21 PM, Babu Moger wrote:
>>>> +/*
>>>> + * Send an IPI to the domain to assign the counter to RMID, event pair.
>>>> + */
>>>> +int resctrl_arch_assign_cntr(struct rdt_resource *r, struct rdt_mon_domain *d,
>>>> +			     enum resctrl_event_id evtid, u32 rmid, u32 closid,
>>>> +			     u32 cntr_id, bool assign)
>>>
>>> Looking ahead this is also called when config of existing assigned counter is
>>> changed. Should this thus perhaps be resctrl_arch_config_cntr()? 
>>
>> We have a matching resctrl_arch_assign_cntr() and
>> resctrl_arch_unassign_cntr() pair.
> 
> hmmm ... resctrl_arch_unassign_cntr() does not exist in this version of the series.

My bad. Confused with different versions.

Sure. Will change it resctrl_arch_config_cntr().


> 
>>
>> If we change resctrl_arch_config_cntr() then we need to change
>> resctrl_arch_unassign_cntr to resctrl_arch_unconfig_cntr().
>>
>> Should we change both?
>>
>>
>>>
>>>> +{
>>>> +	struct rdt_hw_mon_domain *hw_dom = resctrl_to_arch_mon_dom(d);
>>>> +	union l3_qos_abmc_cfg abmc_cfg = { 0 };
>>>> +	struct arch_mbm_state *arch_mbm;
>>>> +
>>>> +	abmc_cfg.split.cfg_en = 1;
>>>
>>> Just to confirm ... a counter remains "configured" from the hardware side whether it
>>> is assigned from resctrl perspective or not? It seems to me that once a counter is
>>> "unassigned" from resctrl perspective it needs no more context about that
>>> counter, yet it remains configured from hardware side?
>>
>> That is correct.
>> When unassigned, we are setting cntr_en = 0, so there is no counting. But
>> in hardware perspective it is still configured.
> 
> I think I misunderstood the "configured in hardware" to equate to "assigned by
> OS" when in fact it is just a bit to indicate when hardware makes changes
> requested by MSR write.
> 

That is correct. Hardware makes the changes only when cfg_en = 1.
Otherwise writing the MSR has no effect.
-- 
Thanks
Babu Moger