[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <ZjO4LXqGcy4bwsn4@e133380.arm.com>
Date: Thu, 2 May 2024 16:58:37 +0100
From: Dave Martin <Dave.Martin@....com>
To: Amit Singh Tomar <amitsinght@...vell.com>
Cc: Reinette Chatre <reinette.chatre@...el.com>,
James Morse <james.morse@....com>, x86@...nel.org,
linux-kernel@...r.kernel.org, Fenghua Yu <fenghua.yu@...el.com>,
Thomas Gleixner <tglx@...utronix.de>,
Ingo Molnar <mingo@...hat.com>, Borislav Petkov <bp@...en8.de>,
H Peter Anvin <hpa@...or.com>, Babu Moger <Babu.Moger@....com>,
shameerali.kolothum.thodi@...wei.com,
D Scott Phillips OS <scott@...amperecomputing.com>,
carl@...amperecomputing.com, lcherian@...vell.com,
bobo.shaobowang@...wei.com, tan.shaopeng@...itsu.com,
baolin.wang@...ux.alibaba.com, Jamie Iles <quic_jiles@...cinc.com>,
Xin Hao <xhao@...ux.alibaba.com>, peternewman@...gle.com,
dfustini@...libre.com, David Hildenbrand <david@...hat.com>,
Rex Nie <rex.nie@...uarmicro.com>
Subject: Re: [PATCH v1 28/31] x86/resctrl: Drop __init/__exit on assorted
symbols
On Wed, May 01, 2024 at 09:51:51PM +0530, Amit Singh Tomar wrote:
>
> > > > I think James will need to comment on this, but I think that yes, it
> > > > is probably appropriate to require a reboot. I think an MPAM error
> > > > interrupt should only happen if the software did something wrong, so
> > > > it's a bit like hitting a BUG(): we don't promise that everything works
> > > > 100% properly until the system is restarted. Misbehaviour should be
> > > > contained to MPAM though.
> > > >
> > > if "resctrl" is nonfunctional in this state, then this comment[1] here does
> > > *not* make sense.
> > >
> > > "restore any modified controls to their reset values."
> >
> > Can you clarify what you mean here?
>
> What I meant was, What's the rationale behind restoring the modified
> controls, if user is going to restart the system anyways (in order to use
> MPAM again), but later realized that it is needed so that *non* MPAM loads
> (user may still want to run other things even after MPAM error interrupt)
> would not have any adverse effect with modified controls.
>
> Therefore, taking my statement back.
Ack: we can't force the system to restart without losing data. Really,
the decision about when and whether to attempt a graceful shutdown or
reboot should be left to userspace. But until userspace does shut down
the system, we do our best to behave as if the broken part of the system
(MPAM) were not present at all.
[...]
Cheers
---Dave
Powered by blists - more mailing lists