Re: [PATCH v7 08/11] arm_mpam: prepare mon_sel locking for MPAM-Fb
Gavin Shan <[email protected]> Tue, 4 Aug 2026 13:58:37 +1000
| Newsgroups | org.kernel.vger.linux-acpi,org.infradead.lists.linux-arm-kernel,org.kernel.vger.linux-kernel |
|---|---|
| Message-ID | <[email protected]> |
On 8/1/26 3:03 AM, Andre Przywara wrote: > The MSC MON_SEL register needs to be accessed from hardirq for the overflow > interrupt, and when taking an IPI to access these registers on platforms > where MSCs are not accesible from every CPU. This makes an irqsave > spinlock the obvious lock to protect these registers. On systems with > MPAM-Fb mailbox MSC access it must be able to sleep, meaning a mutex must > be used. So MPAM-Fb platforms cannot support an overflow interrupt easily. > Clearly these two methods can't exist for one MSC at the same time. > > Change the mon_sel locking wrapper function to only use a spinlock when > the MSC is accessed directly via MMIO. In case of MPAM-Fb, we use a > mutex, but only if we are in a sleepable context. If that's not the > case, we return an error. This should not happen, as MPAM-Fb by design > does not require an MSC access to happen from a specific CPU, so there > is no need for any IPIs or preemption disabling to satisfy CPU > constraints. And since overflow interrupts are not supported at the moment > anyway, we also wouldn't meet the other case. > Bailing out early is already happening in rare occasions today. > > Signed-off-by: Andre Przywara <[email protected]> > Reviewed-by: Jonathan Cameron <[email protected]> > --- > drivers/resctrl/mpam_devices.c | 6 +++++- > drivers/resctrl/mpam_internal.h | 38 +++++++++++++++++++++++++++------ > 2 files changed, 36 insertions(+), 8 deletions(-) > Reviewed-by: Gavin Shan <[email protected]>