[Zesty][PATCH v2 00/13] POWER9 XIVE: msgsnd/doorbell IPI support(backport)

[Seth Forshee]

On Wed, May 24, 2017 at 01:59:14PM -0300, Gustavo L F Walbon wrote:
> 
> 
> On 05/24/2017 09:54 AM, Seth Forshee wrote:
> > On Tue, May 23, 2017 at 10:27:35AM -0300, Gustavo Walbon wrote:
> > > Buglink : http://bugs.launchpad.net/bugs/1691973
> > > 
> > > The backport was requested for 16.04.3 HWE to be enabled the XIVE
> > > feature on the POWER9 systems.
> > > 
> > > The tests were done using the Sysbench for CPU,fileIO and Threads tests,
> > > and the FIO tester to write directly on disk without buffering. All
> > >   tests were performed in order to stress the machine using its 32
> > > threads of CPUs for 12 hr.
> > > 
> > > The commits below were cherry-pick to enable XIVE features.
> > > 
> > > The fixing from Michael Ellerman which it solved the kernel
> > > crash while the starting boot of the machine.
> > > 
> > > Benjamin Herrenschmidt (5):
> > >    powerpc/xive: Native exploitation of the XIVE interrupt controller
> > >    powerpc/powernv: Add XIVE related definitions to opal-api.h
> > >    powerpc: Add more PPC bit conversion macros
> > >    powerpc: Add optional smp_ops->prepare_cpu SMP callback
> > >    powerpc/smp: Remove migrate_irq() custom implementation
> > > 
> > > Douglas Miller (1):
> > >    powerpc/xmon: Dump memory in CPU endian format
> > > 
> > > Michael Ellerman (1):
> > >    powerpc/powernv: Fix oops on P9 DD1 in cause_ipi()
> > > 
> > > Nicholas Piggin (6):
> > >    powerpc/64s: Add msgp facility unavailable log string
> > >    powerpc/64s: Add SCV FSCR bit for ISA v3.0
> > >    powerpc: Change the doorbell IPI calling convention
> > >    powerpc: Introduce msgsnd/doorbell barrier primitives
> > >    powerpc/64s: Avoid a branch for ppc_msgsnd
> > >    powerpc/powernv: POWER9 support for msgsnd/doorbell IPI
> > I've cherry picked most of these to artful/master-next (except for one
> > or two that were already in 4.11), but in the process I noticed a few
> > problems with this submission.
> Do you suggest another version of patch or is it unnecessary?

I guess that depends whether or not the stable team wants to fix them up
for you when they apply the patches. I won't presume to speak for them.

> > 
> > First, the patches say "cherry picked from ... linux-next", but all the
> > patches are actually in Linus' tree as of 4.12-rc1, so the "linux-next"
> > is unnecessary.
> > 
> > Second, the bug link line needs to start with the exact string
> > "BugLink:", otherwise our tooling for generating the changelog entries
> > won't recognize it.
> OK, I have made a mistake, sorry.
> > 
> > Finally, I found that some of these patches must have been backports and
> > not clean cherry picks. Whenever you manually resolve conflicts you
> > should change the "cherry picked from ..." line to say "backported from
> > ..." instead.
> In my case there was not necessary a manual fix, all of them was cherry
> pick.

Hmm, strange, because I had to fix up one or two when I cherry picked
them to 4.11. But maybe that's because of some other backports which had
already been applied from one of the other sets of patches.

So assuming that the other things get fixed up:

Acked-by: Seth Forshee <seth.forshee at canonical.com>

Thanks,
Seth