Re: [PATCH v5 19/41] arm_mpam: resctrl: Add CDP emulation

Zeng Heng
2026-02-25T06:25:49Z

On 2026/2/25 1:56, Ben Horgan wrote:
> From: James Morse <james.morse@arm.com>
>
> Intel RDT's CDP feature allows the cache to use a different control value
> depending on whether the accesses was for instruction fetch or a data
> access. MPAM's equivalent feature is the other way up: the CPU assigns a
> different partid label to traffic depending on whether it was instruction
> fetch or a data access, which causes the cache to use a different control
> value based solely on the partid.
>
> MPAM can emulate CDP, with the side effect that the alternative partid is
> seen by all MSC, it can't be enabled per-MSC.
>
> Add the resctrl hooks to turn this on or off. Add the helpers that match a
> closid against a task, which need to be aware that the value written to
> hardware is not the same as the one resctrl is using.
>
> Update the 'arm64_mpam_global_default' variable the arch code uses during
> context switch to know when the per-cpu value should be used instead. Also,
> update these per-cpu values and sync the resulting mpam partid/pmg
> configuration to hardware.
>
> resctrl can enable CDP for L2 caches, L3 caches or both. When it is enabled
> by one and not the other MPAM globally enabled CDP but hides the effect
> on the other cache resource. This hiding is possible as CPOR is the only
> supported cache control and that uses a resource bitmap; two partids with
> the same bitmap act as one.
>
> Awkwardly, the MB controls don't implement CDP and CDP can't be hidden as
> the memory bandwidth control is a maximum per partid which can't be
> modelled with more partids. If the total maximum is used for both the data
> and instruction partids then then the maximum may be exceeded and if it is
> split in two then the one using more bandwidth will hit a lower
> limit. Hence, hide the MB controls completely if CDP is enabled for any
> resource.
>
> Tested-by: Gavin Shan <gshan@redhat.com>
> Tested-by: Shaopeng Tan <tan.shaopeng@jp.fujitsu.com>
> Tested-by: Peter Newman <peternewman@google.com>
> Tested-by: Zeng Heng <zengheng4@huawei.com>
> CC: Dave Martin <Dave.Martin@arm.com>
> CC: Amit Singh Tomar <amitsinght@marvell.com>
> Reviewed-by: Shaopeng Tan <tan.shaopeng@jp.fujitsu.com>
> Reviewed-by: Jonathan Cameron <jonathan.cameron@huawei.com>
> Signed-off-by: James Morse <james.morse@arm.com>
> Signed-off-by: Ben Horgan <ben.horgan@arm.com>
> ---
> Changes since rfc:
> Fail cdp initialisation if there is only one partid
> Correct data/code confusion
>
> Changes since v2:
> Don't include unused header
>
> Changes since v3:
> Update the per-cpu values and sync to h/w
>
> Changes since v4:
> Enable separately for L2 and L3
> Disable MB controls if CDP enabled
> Consider cdp hiding in resctrl_arch_update_one()

[...]

@ -245,6 +338,14 @@ u32 resctrl_arch_get_config(struct rdt_resource *r,
struct rdt_ctrl_domain *d,
> dom = container_of(d, struct mpam_resctrl_dom, resctrl_ctrl_dom);
> cprops = &res->class->props;
>
> + /*
> + * When CDP is enabled, but the resource doesn't support it,
> + * the control is cloned across both partids.
> + * Pick one at random to read:
> + */
> + if (mpam_resctrl_hide_cdp(r->rid))
> + type = CDP_DATA;
> +

Yes, I have observed that this issue had already been addressed in
resctrl_arch_get_config() before the mpam_resctrl_glue_v4 release.

> partid = resctrl_get_config_index(closid, type);
> cfg = &dom->ctrl_comp->cfg[partid];
>
> @@ -272,6 +373,7 @@ u32 resctrl_arch_get_config(struct rdt_resource *r, struct rdt_ctrl_domain *d,
> int resctrl_arch_update_one(struct rdt_resource *r, struct rdt_ctrl_domain *d,
> u32 closid, enum resctrl_conf_type t, u32 cfg_val)
> {
> + int err;
> u32 partid;
> struct mpam_config cfg;
> struct mpam_props *cprops;
> @@ -289,6 +391,9 @@ int resctrl_arch_update_one(struct rdt_resource *r, struct rdt_ctrl_domain *d,
> dom = container_of(d, struct mpam_resctrl_dom, resctrl_ctrl_dom);
> cprops = &res->class->props;
>
> + if (mpam_resctrl_hide_cdp(r->rid))
> + t = CDP_DATA;
> +

Fix for resctrl_arch_update_one() has been confirmed.

Reviewed-by: Zeng Heng <zengheng4@huawei.com>

Best regards,
Zeng Heng