Re: [PATCH v2 10/29] arm_mpam: Add cpuhp callbacks to probe MSC hardware

James Morse
2025-09-29T17:44:22Z

Hi Ben,

On 12/09/2025 11:42, Ben Horgan wrote:
> On 9/10/25 21:42, James Morse wrote:
>> Because an MSC can only by accessed from the CPUs in its cpu-affinity
>> set we need to be running on one of those CPUs to probe the MSC
>> hardware.
>>
>> Do this work in the cpuhp callback. Probing the hardware will only
>> happen before MPAM is enabled, walk all the MSCs and probe those we can
>> reach that haven't already been probed as each CPU's online call is made.
>>
>> This adds the low-level MSC register accessors.
>>
>> Once all MSCs reported by the firmware have been probed from a CPU in
>> their respective cpu-affinity set, the probe-time cpuhp callbacks are
>> replaced. The replacement callbacks will ultimately need to handle
>> save/restore of the runtime MSC state across power transitions, but for
>> now there is nothing to do in them: so do nothing.
>>
>> The architecture's context switch code will be enabled by a static-key,
>> this can be set by mpam_enable(), but must be done from process context,
>> not a cpuhp callback because both take the cpuhp lock.
>> Whenever a new MSC has been probed, the mpam_enable() work is scheduled
>> to test if all the MSCs have been probed. If probing fails, mpam_disable()
>> is scheduled to unregister the cpuhp callbacks and free memory.
>>
>> CC: Lecopzer Chen <lecopzerc@nvidia.com>
>> Signed-off-by: James Morse <james.morse@arm.com>
>> ---
>> Changes since v1:
>> * Removed register bounds check. If the firmware tables are wrong the
>> resulting translation fault should be enough to debug this.
>> * Removed '&' in front of a function pointer.
>> * Pulled mpam_disable() into this patch.
>> * Disable mpam when probing fails to avoid extra work on broken platforms.
>> * Added mpam_disbale_reason as there are now two non-debug reasons for this
>> to happen.
>
> Looks good to me.
>
> Reviewed-by: Ben Horgan <ben.horgan@arm.com>

Thanks!

James