Re: [PATCH v2 23/45] arm_mpam: resctrl: Add rmid index helpers
From: Jonathan Cameron <jonathan.cameron@huawei.com>
Date: 2026-01-06 14:04:52
Also in:
kvmarm, lkml
On Tue, 6 Jan 2026 11:33:44 +0000 Ben Horgan [off-list ref] wrote:
Hi Jonathan, On 1/6/26 11:21, Jonathan Cameron wrote:quoted
On Fri, 19 Dec 2025 18:11:25 +0000 Ben Horgan [off-list ref] wrote:quoted
From: James Morse <james.morse@arm.com> Because MPAM's pmg aren't identical to RDT's rmid, resctrl handles some data structures by index. This allows x86 to map indexes to RMID, and MPAM to map them to partid-and-pmg. Add the helpers to do this. Signed-off-by: James Morse <james.morse@arm.com> Signed-off-by: Ben Horgan <ben.horgan@arm.com>one comment inline. I messed around with GENMASK + field_prep()/field_get() - new versions of these with no need for runtime constant masks, but it ended up as not that much more readable than what you have here. Reviewed-by: Jonathan Cameron <jonathan.cameron@huawei.com>quoted
--- Changes since rfc: Use ~0U instead of ~0 in lhs of left shift --- drivers/resctrl/mpam_resctrl.c | 28 ++++++++++++++++++++++++++++ include/linux/arm_mpam.h | 3 +++ 2 files changed, 31 insertions(+)diff --git a/drivers/resctrl/mpam_resctrl.c b/drivers/resctrl/mpam_resctrl.c index 4275b1a85887..bdbc5504964b 100644 --- a/drivers/resctrl/mpam_resctrl.c +++ b/drivers/resctrl/mpam_resctrl.c@@ -120,6 +120,34 @@ u32 resctrl_arch_get_num_closid(struct rdt_resource *ignored) return mpam_partid_max + 1; } +u32 resctrl_arch_system_num_rmid_idx(void) +{ + u8 closid_shift = fls(mpam_pmg_max); + u32 num_partid = resctrl_arch_get_num_closid(NULL); + + return num_partid << closid_shift;Given I think you restrict mpam_pmg_max to be power of 2 elsewhere, doesn't this end up the same as something like return mpam_pmg_max * resctrl_arch_get_num_closid(NULL); Maybe its worth keeping it in the form you have here as it sort of provides documentation for how you pack those IDsWe only warn if (mpam_pmg_max + 1) is a power of 2 and so I'll keep this as it is, although yours is equivalent in the expected case.
Do the resulting 'holes' in the values that are valid here cause trouble it isn't power of 2?
quoted
quoted
+}Thanks, Ben