Hi Ben,

On 28/08/2025 14:12, Ben Horgan wrote:

On 8/22/25 16:29, James Morse wrote:

quoted

CPUs can generate traffic with a range of PARTID and PMG values,
but each MSC may have its own maximum size for these fields.
Before MPAM can be used, the driver needs to probe each RIS on
each MSC, to find the system-wide smallest value that can be used.

While doing this, RIS entries that firmware didn't describe are create
under MPAM_CLASS_UNKNOWN.

While we're here, implement the mpam_register_requestor() call
for the arch code to register the CPU limits. Future callers of this
will tell us about the SMMU and ITS.

quoted

diff --git a/drivers/resctrl/mpam_devices.c b/drivers/resctrl/mpam_devices.c
index 9d6516f98acf..012e09e80300 100644
--- a/drivers/resctrl/mpam_devices.c
+++ b/drivers/resctrl/mpam_devices.c

@@ -106,6 +116,74 @@ static inline u32 _mpam_read_partsel_reg(struct mpam_msc *msc, u16 reg)

quoted

+int mpam_register_requestor(u16 partid_max, u8 pmg_max)
+{
+	int err = 0;
+
+	lockdep_assert_irqs_enabled();
+
+	spin_lock(&partid_max_lock);
+	if (!partid_max_init) {
+		mpam_partid_max = partid_max;
+		mpam_pmg_max = pmg_max;
+		partid_max_init = true;
+	} else if (!partid_max_published) {
+		mpam_partid_max = min(mpam_partid_max, partid_max);
+		mpam_pmg_max = min(mpam_pmg_max, pmg_max);

Do we really need to reduce these maximum here? If, say, we add an SMMU
requester which supports fewer partids than the cpus don't we want to be
able to carry on using those partids from the cpus. In this case the
SMMU requestor can, without risk of error interrupts, just use all the
partids it supports.

How would it do that?

We're probably going to expose that SMMU, or the devices behind it, via resctrl. You can
create 10 control groups in resctrl - but can't assign the SMMU/devices to the last two
because it doesn't actually support that many...


Thanks,

James