[PATCH v3 41/47] arm_mpam: Generate a configuration for min controls

[Ben Horgan]

Hi Shanker,

On 1/31/26 02:30, Shanker Donthineni wrote:
> Hi Ben,
> 
> On 1/30/2026 8:17 AM, Ben Horgan wrote:
>> External email: Use caution opening links or attachments
>>
>>
>> Hi Fenghua, Jonathan,
>>
>> On 1/13/26 15:39, Jonathan Cameron wrote:
>>> On Mon, 12 Jan 2026 16:59:08 +0000
>>> Ben Horgan <ben.horgan at arm.com> wrote:
>>>
>>>> From: James Morse <james.morse at arm.com>
>>>>
>>>> MPAM supports a minimum and maximum control for memory bandwidth. The
>>>> purpose of the minimum control is to give priority to tasks that are
>>>> below
>>>> their minimum value. Resctrl only provides one value for the bandwidth
>>>> configuration, which is used for the maximum.
>>>>
>>>>
>>>> Hence, I'll drop this patch, and update the mbw_min default to be
>>>> 0xFFFF
>>>> and for the value not to change even if mbw_max changes. I think this
>>>> leaves us in the best position going forward without any heuristics
>>>> that
>>>> may come back to bite us later when proper support for a schema
>>>> supporting mbw_min is added to resctrl.
> 
> Background: I previouslyshared original fix(seecodesnippet below) with
> James Morse
> ~2 years ago to address the errata, which explicitly recommends usinga
> 5% gap for
> mitigation of the Hardware issue (the problem described in commit text
> of T241-MPAM-4)
> 
> For some reason theoriginalimplementationwas splitinto two patches:
>   - Generic change applicable toall chips
>   - Specific fixfor Graceerrata T241-MPAM-4
> >
> Issue: Dropping this patch impacts[PATCH v3 45/47] forthe errata fix. If
> removalis
> necessary, please mergethis changeinto the T241-MPAM-4-specific patch.


What's the behaviour on T241 when MBW_MIN is always 0xFFFF?

I'm worried if we make a policy decision of how to set MBW_MIN based on
MBW_MAX for this platform then we won't be able to support a
configurable MBW_MIN in the future for this platform. As when MBW_MIN
support is added in resctrl the user's configuration for this platform
would change meaning on kernel upgrade.

> 
> --- a/drivers/platform/mpam/mpam_devices.c
> +++ b/drivers/platform/mpam/mpam_devices.c
> @@ -1190,8 +1190,12 @@ static void mpam_reprogram_ris_partid(struct
> mpam_msc_ris *ris, u16 partid, rprops->mbw_pbm_bits);
>          }
> -       if (mpam_has_feature(mpam_feat_mbw_min, rprops))
> -               mpam_write_partsel_reg(msc, MBW_MIN, 0);
> +       if (mpam_has_feature(mpam_feat_mbw_min, rprops)) {
> +               if (mpam_has_feature(mpam_feat_mbw_max, cfg))
> +                       mpam_write_partsel_reg(msc, MBW_MIN, cfg->mbw_min);
> +               else
> +                       mpam_write_partsel_reg(msc, MBW_MIN, 0);
> +       }
>         if (mpam_has_feature(mpam_feat_mbw_max, rprops)) {
>                 if (mpam_has_feature(mpam_feat_mbw_max, cfg)) @@
> -2332,6 +2336,31 @@ static int __write_config(void *arg)
>          return 0;
>   }
> +static void mpam_extend_config(struct mpam_class *class, struct
> mpam_config *cfg)
> +{
> +       struct mpam_props *cprops = &class->props;
> +       u32 min, delta;
> +
> +       /*
> +        * MAX and MIN should be set together. If only one is provided,
> +        * generate a configuration for the other. If only one control
> +        * type is supported, the other value will be ignored.
> +        *
> +        * Resctrl can only configure the MAX.
> +        *
> +        * Parts affected by Nvidia's T241-MPAM-4 depend on this occurring,
> +        * and recommend a 5% difference.
> +        */
> +       if (mpam_has_feature(mpam_feat_mbw_max, cfg) &&
> +           !mpam_has_feature(mpam_feat_mbw_min, cfg)){
> +               delta = ((5 * MPAMCFG_MBW_MAX_MAX) / 100) - 1;
> +               min = max_t(s32, cfg->mbw_max - delta, BIT(cprops-
>>bwa_wd));
> +
> +               cfg->mbw_min = max_t(s32, cfg->mbw_max - delta, BIT(16 -
> cprops->bwa_wd));
> +               mpam_set_feature(mpam_feat_mbw_min, cfg);
> +       }
> +}
> 
> Shanker
> 

Thanks,

Ben