Re: [PATCH v3 14/16] arm_mpam: add MPAM-Fb MSC firmware access support
Andre Przywara <[email protected]>
| Newsgroups | gmane.linux.kernel,gmane.linux.acpi.devel,gmane.linux.ports.arm.kernel |
|---|---|
| Message-ID | <[email protected]> |
Hi Ben, On 7/15/26 18:17, Ben Horgan wrote: > Hi Andre, > > On 7/10/26 15:45, 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 >> SCMI message generation and handshake, for just the fields we need. >> >> [1] https://developer.arm.com/documentation/den0144/latest >> >> Signed-off-by: Andre Przywara <[email protected]> >> --- >> drivers/resctrl/Makefile | 2 +- >> drivers/resctrl/mpam_devices.c | 26 +++- >> drivers/resctrl/mpam_fb.c | 208 ++++++++++++++++++++++++++++++++ >> drivers/resctrl/mpam_internal.h | 20 +++ >> include/linux/arm_mpam.h | 2 +- >> 5 files changed, 251 insertions(+), 7 deletions(-) >> create mode 100644 drivers/resctrl/mpam_fb.c >> [ ... ] >> diff --git a/drivers/resctrl/mpam_fb.c b/drivers/resctrl/mpam_fb.c >> new file mode 100644 >> index 000000000000..7d7409910f28 >> --- /dev/null >> +++ b/drivers/resctrl/mpam_fb.c >> @@ -0,0 +1,208 @@ [ ... ] >> +static int mpam_fb_send_request(struct mpam_pcc_chan *pcc_chan, u32 msc_id, >> + u16 reg, u32 *result, int mpam_fb_command) >> +{ >> + unsigned int token = atomic_inc_return(&mpam_fb_token); >> + struct acpi_pcct_ext_pcc_shared_memory *pcc_shmem; >> + struct pcc_mbox_chan *chan; >> + void __iomem *payload_ofs; >> + u32 status; >> + int ret; >> + >> + if (!pcc_chan) >> + return -ENODEV; >> + >> + chan = pcc_chan->pcc_chan; >> + >> + guard(mutex)(&pcc_chan->pcc_chan_lock); >> + >> + switch (mpam_fb_command) { >> + case MPAM_MSC_WRITE_CMD: >> + ret = mpam_fb_build_write_message(msc_id, reg, *result, >> + token, chan->shmem); >> + break; >> + case MPAM_MSC_READ_CMD: >> + ret = mpam_fb_build_read_message(msc_id, reg, >> + token, chan->shmem); >> + break; >> + case MPAM_PROTOCOL_VERSION: >> + ret = mpam_fb_build_version_message(token, chan->shmem); >> + break; >> + } >> + if (ret < 0) >> + return ret; >> + >> + ret = mbox_send_message(chan->mchan, NULL); >> + if (ret < 0) >> + return ret; >> + >> + pcc_shmem = chan->shmem; >> + payload_ofs = chan->shmem + sizeof(*pcc_shmem); >> + status = readl(&pcc_shmem->command); >> + if (FIELD_GET(MPAM_MSC_TOKEN_MASK, status) != token) >> + return -ETIMEDOUT; >> + >> + ret = readl(payload_ofs + 0x0); >> + if (ret < 0) { >> + switch (ret) { >> + case MPAM_FB_ERR_NOT_SUPPORTED: >> + return -EOPNOTSUPP; >> + case MPAM_FB_ERR_INVALID_PARAMETERS: >> + return -EINVAL; >> + case MPAM_FB_ERR_NOT_FOUND: >> + return -ENOENT; >> + case MPAM_FB_ERR_OUT_OF_RANGE: >> + return -ERANGE; > > Does it make sense to have individual translations for any of the other errors? Which one do you > think is most likely? I don't think it's really that useful. For most errors there is no good mapping between MPAM-Fb and the generic Linux error codes, and when they are propagated up it's unclear what they mean, really. I wonder if we should print or log the original error code, but otherwise not sweat it to find a perfect match for every MPAM-Fb code. Cheers, Andre > > Thanks, > > Ben > >> + default: >> + return -EINVAL; >> + } >> + } >> + >> + if (mpam_fb_command != MPAM_MSC_WRITE_CMD) >> + *result = readl(payload_ofs + 0x4); >> + >> + return 0; >> +} >> + >> +int mpam_fb_send_read_request(struct mpam_msc *msc, u16 reg, u32 *result) >> +{ >> + return mpam_fb_send_request(msc->pcc_chan, msc->mpam_fb_msc_id, >> + reg, result, MPAM_MSC_READ_CMD); >> +} >> + >> +int mpam_fb_send_write_request(struct mpam_msc *msc, u16 reg, u32 value) >> +{ >> + return mpam_fb_send_request(msc->pcc_chan, msc->mpam_fb_msc_id, >> + reg, &value, MPAM_MSC_WRITE_CMD); >> +} >> + >> +int mpam_fb_get_protocol_version(struct mpam_msc *msc) >> +{ >> + u32 version; >> + int ret; >> + >> + ret = mpam_fb_send_request(msc->pcc_chan, 0, >> + 0, &version, MPAM_PROTOCOL_VERSION); >> + if (ret) >> + return ret; >> + >> + return version; >> +} >> diff --git a/drivers/resctrl/mpam_internal.h b/drivers/resctrl/mpam_internal.h >> index 7b6e0df904f8..c3c4ddb4a561 100644 >> --- a/drivers/resctrl/mpam_internal.h >> +++ b/drivers/resctrl/mpam_internal.h >> @@ -11,6 +11,7 @@ >> #include <linux/io.h> >> #include <linux/jump_label.h> >> #include <linux/llist.h> >> +#include <linux/mailbox_client.h> >> #include <linux/mutex.h> >> #include <linux/resctrl.h> >> #include <linux/spinlock.h> >> @@ -57,6 +58,15 @@ struct mpam_garbage { >> struct platform_device *pdev; >> }; >> >> +struct mpam_pcc_chan { >> + struct list_head pcc_chans; >> + struct mbox_client pcc_cl; >> + struct pcc_mbox_chan *pcc_chan; >> + struct mutex pcc_chan_lock; /* only one message at a time */ >> + int subspace_id; >> + int refcount; >> +}; >> + >> struct mpam_msc { >> /* member of mpam_all_msc */ >> struct list_head all_msc_list; >> @@ -66,6 +76,8 @@ struct mpam_msc { >> >> /* Not modified after mpam_is_enabled() becomes true */ >> enum mpam_msc_iface iface; >> + struct mpam_pcc_chan *pcc_chan; >> + int mpam_fb_msc_id; /* in its own name space */ >> u32 nrdy_usec; >> cpumask_t accessibility; >> bool has_extd_esr; >> @@ -501,6 +513,14 @@ static inline void mpam_resctrl_offline_cpu(unsigned int cpu) { } >> static inline void mpam_resctrl_teardown_class(struct mpam_class *class) { } >> #endif /* CONFIG_RESCTRL_FS */ >> >> +/* MPAM-Fb Firmware-backed protocol wrappers */ >> +int mpam_fb_send_read_request(struct mpam_msc *msc, u16 reg, u32 *result); >> +int mpam_fb_send_write_request(struct mpam_msc *msc, u16 reg, u32 value); >> +int mpam_fb_get_protocol_version(struct mpam_msc *msc); >> + >> +#define PCC_TYPE3_MSG_PAYLOAD_OFS 0x10 >> +#define MPAM_FB_MAX_MSG_SIZE (PCC_TYPE3_MSG_PAYLOAD_OFS + 4 * sizeof(u32)) >> + >> /* >> * MPAM MSCs have the following register layout. See: >> * Arm Memory System Resource Partitioning and Monitoring (MPAM) System >> diff --git a/include/linux/arm_mpam.h b/include/linux/arm_mpam.h >> index f92a36187a52..002f56e15362 100644 >> --- a/include/linux/arm_mpam.h >> +++ b/include/linux/arm_mpam.h >> @@ -12,7 +12,7 @@ struct mpam_msc; >> >> enum mpam_msc_iface { >> MPAM_IFACE_MMIO, /* a real MPAM MSC */ >> - MPAM_IFACE_PCC, /* a fake MPAM MSC */ >> + MPAM_IFACE_PCC, /* using the MPAM-Fb firmware redirection */ >> }; >> >> enum mpam_class_types { >