[Fwd: [PATCH] ppc64: 2.6 altivec support, sys_swapcontext & signal32 rework]

[Steve Munroe]

Ben thanks.

With Tom Gall's I have your kernel running on my G5. This was pull from
your BK about our Friday noon. We had a few glitches and had to deconfigure
NVRAM and pmac_seriel.

The plan is to build glibc with some VMX patches and start testing next
week.

Steven J. Munroe
Power Linux Toolchain Architect
IBM Corporation, Linux Technology Center




                      Benjamin Herrenschmidt
                      <benh at kernel.crashing.org>          To:       linuxppc64-dev at lists.linuxppc.org
                      Sent by:                            cc:
                      owner-linuxppc64-dev at lists.l        Subject:  [Fwd: [PATCH] ppc64: 2.6 altivec support, sys_swapcontext &       signal32
                      inuxppc.org                          rework]


                      11/30/03 11:15 PM






(Re-post with the patch bzip2'ed...)

Hi !

It wasn't very easy to split this patch, so here it is in one piece
for now. It does a few things:

 - Adds basic Altivec support to the context switching code
 - Adds Altivec support to the 64 bits sigcontext
 - Rewrite part of the signal32 compat code based on the new
   ppc32 implementation, with Altivec support in the contexts,
   factors out some sigset flipping code, and fixes a long standing
   bug where an 32 bits RT context would have an incorrectly flipped
   sigset (a 64 bits one instead of a 32 bits one).
 - Adds sys_swapcontext syscall (and sys32_swapcontext) for kernel
   based implementation of {set,get,swap}_context with Altivec
   support

So far, it appears to work fine (when run as part of my G5 kernel which
contains a bunch of other changes though). It would need some more testing
hopefully.

What is needed now is a glibc implementation of the ucontext calls for
both 32 and 64 bits that makes use of the new sys_swapcontext, at least
with 2.6. I may give it a try, but I'm sure somebody more familiar with
glibc than I am would get this done much much more quickly... So if you
are that person, please speak up ;)

Regarding the details of the Altivec stuff: On a ppc64 signal frame, a
kernel that supports altivec (AT_HWCAP) will always fill properly the
pointer to the altivec context. In there, VRSAVE is always set, regardless
of the usage of altivec done by the process. MSR:VEC in the regs context
will be set is the other altivec registers (vr0..31 and vscr) have valid
values in the context.

It is important to split vrsave from the rest of the context as a process
may set vrsave prior to doing its first vector operation, and get preempted
with a signal in between those, thus having a valid vrsave context that
needs to be saved & restored without having taken its first altivec
exception yet, thus not having an altivec context to save yet.

I'm not sure what's the best way to deal with the availability of vrsave
on ppc32 contexts, it's a bit more nasty here. (kernel version ?). Some
ppc32 kernels will report supporting altivec via AT_HWCAP without actually
implementing altivec sig/u context stuff. We may need to based ourself on
some kernel versioning here, maybe consider 2.4.23 as the minimum version
to rely on kernel sigcontext containing proper vrsave for ppc32 ?

Ben.




#### ppc64-altivec_and_sig.diff.bz2 has been removed from this note on
December 07, 2003 by Steve Munroe


** Sent via the linuxppc64-dev mail list. See http://lists.linuxppc.org/