Hi Ben,
On 28/08/2025 14:12, Ben Horgan wrote:
> On 8/22/25 16:29, James Morse wrote:
>> 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.
>> 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)
>> +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
