Re: [PATCH v4 06/10] arm_mpam: propagate MSC access errors for state saving function

From: Sudeep Holla

Date: Fri Jul 24 2026 - 08:32:49 EST


On Fri, Jul 24, 2026 at 01:19:14PM +0200, Andre Przywara wrote:
> Hi,
>
> On 7/24/26 12:07, Sudeep Holla wrote:
> > On Thu, Jul 23, 2026 at 05:54:50PM +0200, Andre Przywara wrote:
> > > Allow the mpam_save_mbwu_state() function to return an error, and
> > > propagate read and write errors from the lower level up.
> > >
> > > Signed-off-by: Andre Przywara <andre.przywara@xxxxxxx>
> > > ---
> > > drivers/resctrl/mpam_devices.c | 29 ++++++++++++++++++++++-------
> > > 1 file changed, 22 insertions(+), 7 deletions(-)
> > >
> > > diff --git a/drivers/resctrl/mpam_devices.c b/drivers/resctrl/mpam_devices.c
> > > index bcff53477133..6329443c451f 100644
> > > --- a/drivers/resctrl/mpam_devices.c
> > > +++ b/drivers/resctrl/mpam_devices.c
> > > @@ -1833,22 +1833,37 @@ static int mpam_save_mbwu_state(void *arg)
> > > mon_sel = FIELD_PREP(MSMON_CFG_MON_SEL_MON_SEL, i) |
> > > FIELD_PREP(MSMON_CFG_MON_SEL_RIS, ris->ris_idx);
> > > - mpam_write_monsel_reg(msc, CFG_MON_SEL, mon_sel);
> > > - mpam_read_monsel_reg(msc, CFG_MBWU_FLT, &cur_flt);
> > > - mpam_read_monsel_reg(msc, CFG_MBWU_CTL, &cur_ctl);
> > > - mpam_write_monsel_reg(msc, CFG_MBWU_CTL, 0);
> > > + ret = mpam_write_monsel_reg(msc, CFG_MON_SEL, mon_sel);
> > > + if (ret)
> > > + return ret;
> > > + ret = mpam_read_monsel_reg(msc, CFG_MBWU_FLT, &cur_flt);
> > > + if (ret)
> > > + return ret;
> > > + ret = mpam_read_monsel_reg(msc, CFG_MBWU_CTL, &cur_ctl);
> > > + if (ret)
> > > + return ret;
> >
> > How does it work in general with PCC. Now that you can fail at any point,
> > what happens to the write that occurs before a failed read like above one.
> > Who will take care of erasing those new writes or it doesn't matter ?
> > Just checking as I don't have much knowledge on MPAM intrinsics.
>
> TBH I don't know, but I think we consider MPAM botched at this point, and
> just stop the driver, similar to an error IRQ? But I am not sure this is
> properly implemented at this point. The focus of these first six patches was
> merely to lay the dirty groundwork for *being able* to handle errors, and do
> this now rather than in the future.
>

Well, I agree to some extent, but PCC adds that failure case before which
it wasn't there. So, it is hard to claim that it was botched up before so
let it be. I will let James/Ben to decide if it was already botched up or
PCC addition makes it fragile in terms of error handling.

--
Regards,
Sudeep