lkml.org 
[lkml]   [2017]   [Jul]   [26]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: Qemu problems in -next with 's390/spinlock: add niai spinlock hints'
> > > Hmm, I though that NIAI is a NOP on older machines. A runtime check for
> > > the facility bit is out of the question as the NIAI-7 gets inlined in
> > > the spin_unlock code. So yes, the only available fix is to make the
> > > NIAI hinting conditional on zEC12. Which is quite ugly as we would need
> > > an architecture level set to zEC12 for the distribution kernel to make
> > > use of NIAI.
> >
> > Alternatively you could generate a four-byte nop, and replace that at IPL
> > time with the needed NIAI instruction, if the facility is available. Some
> > sort of "alternative" code patching infrastructure that x86 already has.
> > Not sure if it is worth it, however...
>
> Patching all spin_unlock inlines? There are a lot of callers for this
> function. We could think about an out-of-line spin_unlock and patch this
> single function but then we'd loose the advantage of inlining.
> I do not think it is worthwhile.
>
> I pushed an updated patch to the features branch of s390/linux. Should
> be in linux-next tomorroy. Thanks.

The idea would be to generate an extra section that contains the addresses
of the to be patched instructions, and how they need to be patched. That
section, plus the code that will do the patching could reside in init
data/code sections and would be discarded after. So the additional memory
overhead after initialization would be close to zero.

However an ifdef is fine as well ;)

\
 
 \ /
  Last update: 2017-07-26 09:27    [W:0.071 / U:0.028 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site