Hijacking CPU_FTR_VSX for BGQ QPX

Jimi Xenidis <jimix@pobox.com> wrote:

> Sorry for the pause, lots of other things getting done... questions below.
> 
> On Nov 9, 2012, at 10:33 PM, Michael Neuling <mikey@neuling.org> wrote:
> 
> > Benjamin Herrenschmidt <benh@kernel.crashing.org> wrote:
> > 
> >> On Fri, 2012-11-09 at 11:43 -0600, Jimi Xenidis wrote:
> >>> The CPU_FTR_* values are pretty tight (a few bits left) yes I need to save and restore the QPX registers.
> >>> There are 32 QPX registers, each 32 bytes in size, it is otherwise managed by the FPSCR and MSR[FP]
> >>> 
> >>> I was thinking that I could hijack the VSX, since there is no plan to add it to embedded yet.
> >>> I could be explicit or create an alieas fo the same bit, but the basic effect (after increasing the save area size) would be something like the diff below.
> >>> Thoughts?
> >> 
> >> Don't. Use a different bit, we can always split the mask again if
> >> needed, move more bits to mmu_features etc...
> 
> Ok
> 
> >> 
> >>> -#ifdef CONFIG_VSX
> >>> +#if defined (CONFIG_VSX) && defined(CONFIG_BGQ)
> >>> +# error "This code depends on CONFIG_VSX and CONFIG_BGQ being exclusive
> >>> +#elif defined (CONFIG_VSX)
> >>> +# define _REST_32VSRS(n,c,base) REST_32VSRS(n,c,base)
> >>> +# define _SAVE_32VSRS(n,c,base) SAVE_32VSRS(n,c,base)
> >>> +#elif defined(CONFIG_BGQ)
> >> 
> >> Make a CONFIG_PPC_QPX or something like that specifically for the QPX
> >> stuff that you can then "select" from CONFIG_PPC_BGQ (don't do just
> >> CONFIG_BGQ).
> 
> ack
> 
> >> 
> >> And don't just "hijack" stuff like that, it should be a runtime option,
> >> so add a new set etc... it should be possible to build a kernel that
> >> boots on a BGQ or a hypothetical BookE chip with VSX.
> 
> ack
> > 
> > Yeah both bluegene and VSX are designed for HPC, so it's not completely
> > crazy that someone would put them together.
> 
> Not sure that is possible, since they both "include" FPU state, which
> is why hijacking the the FPU routines is so delicious.

I have this patch in my tree to push upstream at some point.  It packs
all the CPU_FTR_* bits so that we have a few free at the end.

Benh: How about we take this now (or whatever merges).  Then we add a
the new bits we know we need in the near future like PPR, DOORBELLS, TM,
and JIMIS_VERY_CRAZY_BGQ_FPU?  

Or, can we all just post random CPU_FTR bits and you'll (benh) fix the
merge issues?

Mikey

commit 35f9a3ed7065b80013df87e33a832537c2ce224e
Author: Michael Neuling <mikey@neuling.org>
Date:   Fri Nov 30 16:40:56 2012 +1100

    repack 64bit cpu features to remove holes

Hijacking CPU_FTR_VSX for BGQ QPX

Commit Message

Patch