[PATCH v4 00/41] arm_mpam: Add KVM/arm64 and resctrl glue code

[Ben Horgan]

Hi Shaopeng,

On 2/9/26 08:25, Shaopeng Tan (Fujitsu) wrote:
> Hello Ben,
> 
>> This new version of the mpam missing pieces series has a few significant
>> changes in the mpam driver part of the series. The heuristics for deciding
>> if features should be exposed are tightened. This is to fix some
>> inaccuracies and avoid overcommitting before needed - shout if this changes
>> anything on your platform. The final patch adds documentation which
>> explains which features you should expect. The ABMC emulation is dropped
>> for the moment as it requires resctrl changes to support for MPAM without
>> breaking the abi. The default 5% gap for min_bw is dropped in favour of a
>> simple default (kept for grace). The series is based on x86/resctrl [1] as
>> resctrl has telemetry patches queued which change the arch interface.
> 
> Could you please elaborate on why fs/resctrl changes are required to support only the counter assignment part of ABMC?
> Currently, many SoC chips have an insufficient number of memory bandwidth monitors.

Sure. When the counter assignment mode is 'mbm_event; resctrl assumes the mbm events are configurable. 
The 'event_filter' files at
    info/L3_MON/event_configs/<event>/event_filter 
are used to display and set this configuration.

In MPAM event configuration is not supported and so showing a read/writable 'event_filter' file is 
misleading to the user and needs to be hidden for MPAM support.

Just to give you a flavour of the change, here's a hack to show the correct thing for MPAM:

--- a/fs/resctrl/rdtgroup.c
+++ b/fs/resctrl/rdtgroup.c
@@ -2338,6 +2338,9 @@ static int resctrl_mkdir_event_configs(struct rdt_resource *r, struct kernfs_nod
                if (ret)
                        goto out;
 
+               if (!resctrl_arch_is_evt_configurable(mevt->evtid))
+                       continue;
+


> We would be grateful if you could support the counter assignment part of ABMC.

It is not a big change in resctrl but I thought it best to not gate the rest of this series on
an additional change in another subsystem. I am current looking into this and hope to get the 
patches on the list early in the next cycle.

> 
> Best regards,
> Shaopeng TAN
> 
> 
Thanks,

Ben