On Sun, Jul 19, 2026 at 01:40:21PM +0100, Mark Brown wrote:
> On Sun, Jul 19, 2026 at 09:35:53AM +0100, Marc Zyngier wrote:
> > Mark Brown <[email protected]> wrote:
>
> > > I've gone and implemented the first which will suppress the isb() for
> > > current host kernel SME usage, the second two are starting to get more
> > > fiddly than seems sensible to do right now.
>
> > I really wish you didn't optimise anything at all at this stage.
>
> > "Optimisation" is exactly what got us into so much trouble over the
> > past two years, and I really don't want SME in KVM to follow the same
> > trajectory.
>
> > So leave this is a straight ISB, no optimisation. Once you come back
> > with actual data showing that this is a terrible bottleneck affecting
> > real workloads on real HW, we'll look at it. But until then, please
> > keep it as stupid as possible.
>
> I've already left the KVM hypervisor code like that - I only updated the
> code here in the main kernel since that keeps the end effect for
> existing systems and workloads the same. I am aware that there has been
> a great deal of attention paid to the barriers we have in the context
> switch path so I am concerned that other people might have a different
> view on adding one.
FWIW, my view is:
(1) We shouldn't make speculative optimizations. Removing unnecessary
code is fine, within reason, but we shouldn't be adding conditional
logic.
To that end, I'd be happier with an unconditional ISB here.
(2) Optimizations should be benchmarked to some extent, such that we can
decide whether the trade-off is worthwhile.
(3) In this path specifically, if adding an ISB is a problem, then it
calls the wider approach into question.
Is there anyone in particular that you expect feecback from w.r.t.
barriers in this path?
Mark.
