Re: [PATCH v4 08/10] arm_mpam: add MPAM-Fb MSC firmware access support

[Sudeep Holla <sudeep.holla@kernel.org>]

On Fri, Jul 24, 2026 at 01:17:41PM +0200, Andre Przywara wrote:
> Hi Sudeep,
> 
> many thanks for having a look!
> 
> On 7/24/26 11:55, Sudeep Holla wrote:
> > On Thu, Jul 23, 2026 at 05:54:52PM +0200, Andre Przywara wrote:
> > > The Arm MPAM Firmware-backed (Fb) Profile document[1] describes an
> > > alternative way of accessing the "Memory System Components" (MSC) in an
> > > MPAM enabled system.
> > > 
> > > Normally the MSCs are MMIO mapped, but in some implementations this
> > > might not be possible (MSC located outside of the local socket, MSC
> > > mapped secure-only) or desirable (direct MMIO access too slow or needs
> > > to be mediated through a control processor). MPAM-fb standardises a
> > > protocol to abstract MSC accesses, building on the SCMI protocol.
> > > 
> > > Add functions that do an MSC read or write access by redirecting the
> > > request through a firmware interface. For now this done via an ACPI
> > > PCC shared memory and mailbox combination.
> > > 
> > > Since the protocol used is only a small subset of the full SCMI spec,
> > > and the SCMI protocol has no full ACPI support anyway, open-code the
> > > (simple) SCMI message generation, for just the fields we need.
> > > 
> > > [1] https://developer.arm.com/documentation/den0144/latest
> > > 
> > > Signed-off-by: Andre Przywara <andre.przywara@arm.com>
> > > ---
> > >   drivers/resctrl/Makefile        |   2 +-
> > >   drivers/resctrl/mpam_devices.c  |  27 ++++-
> > >   drivers/resctrl/mpam_fb.c       | 197 ++++++++++++++++++++++++++++++++
> > >   drivers/resctrl/mpam_internal.h |  20 ++++
> > >   include/linux/arm_mpam.h        |   2 +-
> > >   5 files changed, 240 insertions(+), 8 deletions(-)
> > >   create mode 100644 drivers/resctrl/mpam_fb.c
> > > 
> > > diff --git a/drivers/resctrl/Makefile b/drivers/resctrl/Makefile
> > > index 4f6d0e81f9b8..097c036724e9 100644
> > > --- a/drivers/resctrl/Makefile
> > > +++ b/drivers/resctrl/Makefile
> > > @@ -1,5 +1,5 @@
> > >   obj-$(CONFIG_ARM64_MPAM_DRIVER)			+= mpam.o
> > > -mpam-y						+= mpam_devices.o
> > > +mpam-y						+= mpam_devices.o mpam_fb.o
> > >   mpam-$(CONFIG_ARM64_MPAM_RESCTRL_FS)		+= mpam_resctrl.o
> > >   ccflags-$(CONFIG_ARM64_MPAM_DRIVER_DEBUG)	+= -DDEBUG
> > > diff --git a/drivers/resctrl/mpam_devices.c b/drivers/resctrl/mpam_devices.c
> > > index e2cb884eacf4..b8108ed4b32c 100644
> > > --- a/drivers/resctrl/mpam_devices.c
> > > +++ b/drivers/resctrl/mpam_devices.c
> > > @@ -181,6 +181,9 @@ static int __mpam_read_reg(struct mpam_msc *msc, u16 reg, u32 *res)
> > >   {
> > >   	WARN_ON_ONCE(!cpumask_test_cpu(smp_processor_id(), &msc->accessibility));
> > > 
> > 
> > The above doesn't make any sense for PCC accesses, perhaps need to be pushed
> > down ?
> 
> Well, the idea was that the mask would always encompass all CPUs when using
> MPAM-Fb, but to consider this an implementation detail of MPAM-Fb.
> We can of course move this out of the way for MPAM-Fb.
> 

I prefer that.

> > 
> > > +	if (msc->iface == MPAM_IFACE_PCC)
> > > +		return mpam_fb_send_read_request(msc, reg, res);
> > > +
> > >   	*res = readl_relaxed(msc->mapped_hwpage + reg);
> > >   	return 0;
> > > @@ -197,9 +200,12 @@ static inline int _mpam_read_partsel_reg(struct mpam_msc *msc, u16 reg,
> > >   static int __mpam_write_reg(struct mpam_msc *msc, u16 reg, u32 val)
> > >   {
> > > -	WARN_ON_ONCE(reg + sizeof(u32) > msc->mapped_hwpage_sz);
> > >   	WARN_ON_ONCE(!cpumask_test_cpu(smp_processor_id(), &msc->accessibility));
> > 
> 
> And by the way: I think the hwpage_sz check should belong to the probe
> function, not be done on every access. Or are there optional registers that
> might not be part of the mapping on devices that don't support them?
> 

No, I was just referring the cpumask and not hwpage_sz check.

-- 
Regards,
Sudeep