Virtualization - Feb 2023 - [PATCH 0/2] vhost: improve livepatch switching for heavily loaded vhost worker kthreads

On Tue, Jan 31, 2023 at 08:38:32AM -0800, Josh Poimboeuf
wrote:
> On Tue, Jan 31, 2023 at 10:22:09AM +0000, Mark Rutland wrote:
> > > Hm, it might be nice if our out-of-line static call
implementation would
> > > automatically do a static key check as part of static_call_cond()
for
> > > NULL-type static calls.
> > > 
> > > But the best answer is probably to just add inline static calls
to
> > > arm64.  Is the lack of objtool the only thing blocking that?
> > 
> > The major issues were branch range limitations (and needing the linker
to add
> > PLTs),
> 
> Does the compiler do the right thing (e.g., force PLT) if the branch
> target is outside the translation unit?  I'm wondering if we could for
> example use objtool to help enforce such rules at the call site.
It's the linker (rather than the compiler) that'll generate the PLT if
the
caller and callee are out of range at link time. There are a few other issues
too (e.g. no guarnatee that the PLT isn't used by multiple distinct callers,
CMODX patching requirements), so we'd have to generate a pseudo-PLT
ourselves
at build time with a patching-friendly code sequence. Ard had a prototype for
that:

  https://lore.kernel.org/linux-arm-kernel/20211105145917.2828911-1-ardb at
kernel.org/

... but that was sufficiently painful that we went with the current static key
approach:

  https://lore.kernel.org/all/20211109172408.49641-1-mark.rutland at arm.com/
> > and painful instruction patching requirements (e.g. the
architecture's
> > "CMODX" rules for Concurrent MODification and eXecution of
instructions). We
> > went with the static key scheme above because that was what our
assembled code
> > generation would devolve to anyway.
> > 
> > If we knew each call-site would only call a particular function or
skip the
> > call, then we could do better (and would probably need something like
objtool
> > to NOP that out at compile time), but since we don't know the
callee at build
> > time we can't ensure we have a PLT in range when necessary.
> 
> Unfortunately most static calls have multiple destinations.
Sure, but here we're just enabling/disabling a call, which we could treat
differently, or wrap at a different level within the scheduler code. I'm
happy
to take a look at that.
> And most don't have the option of being NULL.
Oh, I was under the impression that all could be disabled/skipped, which is
what a NULL target implied.

Thanks,
Mark.