Re: [PATCH 00/33] arm_mpam: Add basic mpam driver

Carl Worth
2025-11-07T23:23:00Z

Ben Horgan <ben.horgan@arm.com> writes:
> This version of the series comes to you from me as James is otherwise
> engaged. I hope I have done his work justice. I've made quite a few
> changes, rework, bugs, typos, all the usual. In order to aid review,
> as Jonathan suggested, I've split out some patches and made an effort
> to minimise the amount of churn between patches.

I've built this and booted on an Ampere system. It ends up reporting a
successful message of:

MPAM enabled with 1 PARTIDs and 1 PMGs

So the code seems happy enough as far as that goes.

But the expected number of PARTIDs on this system is much larger than 1,
(MPAM with a single PARTID would not be useful at all).

> See below for a public branch. No public updated version of the
> snapshot (the rest of the driver) I'm afraid.

Looking closer, it looks like the bogus value of 0 for mpam_partid_max
is because the following patch (which does appear in James' various
snapshots) isn't present yet in the code submitted to this point:

commit 33c1f50970917ac9f2a8e224d850936374df6173
Author: James Morse <james.morse@arm.com>
Date: Fri Jul 4 14:22:30 2025 +0100

arm64: mpam: Advertise the CPUs MPAM limits to the driver

Requestors need to populate the MPAM fields on the interconnect. For
the CPUs these fields are taken from the corresponding MPAMy_ELx
register. Each requestor may have a limit on the largest PARTID or
PMG value that can be used. The MPAM driver has to determine the
system-wide minimum supported PARTID and PMG values.

To do this, the driver needs to be told what each requestor's
limit is.

So, I guess I'm wondering what more I could do to test this code at this
point, prior to merging it.

I'm very interested in seeing this code land upstream as soon as
possible, and I've got access to an implementation to test whatever I
can.

So let me know what else I can do and I'll be glad to contribute my
Tested-by when I've done it.

-Carl