search for: static_call

...making that thing guarantee forward progressm, so > there just isn't too much room to play. > >> We don't have a good alternate patching for function calls yet, but >> that would be something to do for native vs pv. > Going by your jump_label implementation, support for static_call should > be fairly straight forward too, no? > > https://lkml.kernel.org/r/20200624153024.794671356 at infradead.org > Speaking of static_call, I am also looking forward to it. Do you have an idea when that will be merged? Cheers, Longman

...making that thing guarantee forward progressm, so > there just isn't too much room to play. > >> We don't have a good alternate patching for function calls yet, but >> that would be something to do for native vs pv. > Going by your jump_label implementation, support for static_call should > be fairly straight forward too, no? > > https://lkml.kernel.org/r/20200624153024.794671356 at infradead.org > Speaking of static_call, I am also looking forward to it. Do you have an idea when that will be merged? Cheers, Longman

...forward progressm, so > > there just isn't too much room to play. > > > > > We don't have a good alternate patching for function calls yet, but > > > that would be something to do for native vs pv. > > Going by your jump_label implementation, support for static_call should > > be fairly straight forward too, no? > > > > https://lkml.kernel.org/r/20200624153024.794671356 at infradead.org > > > Speaking of static_call, I am also looking forward to it. Do you have an > idea when that will be merged? 0day had one crash on the la...

Excerpts from Waiman Long's message of July 7, 2020 4:39 am: > On 7/6/20 12:35 AM, Nicholas Piggin wrote: >> v3 is updated to use __pv_queued_spin_unlock, noticed by Waiman (thank you). >> >> Thanks, >> Nick >> >> Nicholas Piggin (6): >> powerpc/powernv: must include hvcall.h to get PAPR defines >> powerpc/pseries: move some PAPR

Excerpts from Waiman Long's message of July 7, 2020 4:39 am: > On 7/6/20 12:35 AM, Nicholas Piggin wrote: >> v3 is updated to use __pv_queued_spin_unlock, noticed by Waiman (thank you). >> >> Thanks, >> Nick >> >> Nicholas Piggin (6): >> powerpc/powernv: must include hvcall.h to get PAPR defines >> powerpc/pseries: move some PAPR

...ir amount of time on making that thing guarantee forward progressm, so there just isn't too much room to play. > We don't have a good alternate patching for function calls yet, but > that would be something to do for native vs pv. Going by your jump_label implementation, support for static_call should be fairly straight forward too, no? https://lkml.kernel.org/r/20200624153024.794671356 at infradead.org

...could be useful in conjunction with the ongoing > late microcode loading work that Mihai Carabas and others have been > working on. The whole late-microcode loading stuff is crazy already; you're making it take double bonghits. > Also, there are points of similarity with the ongoing static_call work > which does rewriting of indirect calls. Only in so far as that code patching is involved. An analogy would be comparing having a beer with shooting dope. They're both 'drugs'. > The difference here is that > we need to switch a group of calls atomically and given that...

...could be useful in conjunction with the ongoing > late microcode loading work that Mihai Carabas and others have been > working on. The whole late-microcode loading stuff is crazy already; you're making it take double bonghits. > Also, there are points of similarity with the ongoing static_call work > which does rewriting of indirect calls. Only in so far as that code patching is involved. An analogy would be comparing having a beer with shooting dope. They're both 'drugs'. > The difference here is that > we need to switch a group of calls atomically and given that...

...plicated medium-path logic unfortunately but that's no worse than something like x86 really. >> We don't have a good alternate patching for function calls yet, but >> that would be something to do for native vs pv. > > Going by your jump_label implementation, support for static_call should > be fairly straight forward too, no? > > https://lkml.kernel.org/r/20200624153024.794671356 at infradead.org Nice, yeah it should be. I've wanted this for ages! powerpc is kind of annoying to implement that with limited call range, Hmm, not sure if we'd need a new link...

...plicated medium-path logic unfortunately but that's no worse than something like x86 really. >> We don't have a good alternate patching for function calls yet, but >> that would be something to do for native vs pv. > > Going by your jump_label implementation, support for static_call should > be fairly straight forward too, no? > > https://lkml.kernel.org/r/20200624153024.794671356 at infradead.org Nice, yeah it should be. I've wanted this for ages! powerpc is kind of annoying to implement that with limited call range, Hmm, not sure if we'd need a new link...